Hi Ján,
I think I understand what my server needs to do as you outline below.
Here is an actual (partial) response to a preflight PUT request from
CalDavZap:
Access-Control-Max-Age: 3600
Access-Control-Allow-Headers:
authorization,content-type,if-none-match,x-client
Access-Control-Allow-Methods: OPTIONS, GET, HEAD, PUT, DELETE
Access-Control-Allow-Methods: PROPFIND, REPORT, COPY, MOVE, LOCK, UNLOCK
Access-Control-Allow-Origin: http://localhost
Access-Control-Allow-Credentials: true
What I'm asking is if your client would like to get the ETag from the
response to the actual PUT, would the browser allow it? Do I need to
include Access-Control-Expose-Headers: ETag to allow it?
The reason I ask this particular question is that your client does a
calendar-multiget REPORT immediately following the PUT asking for the
getetag and calendar-data properties. Are you doing this because this
is the only way to get the ETag, or do you want to make sure that the
calendar-data is the same as what you PUT, or both?
Obviously, the ETag should be available in the PUT response and if you
use the Prefer:return=representation header, the server might also give
you the calendar-data in the PUT response body saving a round-trip. See
draft-snell-http-prefer
<http://datatracker.ietf.org/doc/draft-snell-http-prefer/> and
draft-murchison-webdav-prefer
<http://datatracker.ietf.org/doc/draft-murchison-webdav-prefer/>
On 05/29/2013 11:19 AM, Ján Máté wrote:
> Hi Ken,
>
> the problem is not as simple as it looks like. We cannot use "simple" headers, because if a browser detects any cross-domain query (different protocol/domain or port), it will make a "preflight" OPTIONS request and if there are no proper CORS headers in the response, the browser will refuse to make the real request (from JavaScript). There is no way to disable these preflight requests (these are generated internally by browsers).
>
> Correct CORS headers for CardDavMATE/CalDavZAP looks like:
>
> Access-Control-Allow-Origin *
> => everybody can make request to this server
>
> Access-Control-Allow-Methods GET,POST,OPTIONS,PROPFIND,REPORT,PUT,MOVE,DELETE,LOCK,UNLOCK
> => all allowed methods (even if you return something like "unsupported" or "not implemented" for some of them)
>
> Access-Control-Allow-Headers User-Agent,Authorization,Content-type,Depth,If-match,If-None-Match,Lock-Token,Timeout,Destination,Overwrite,X-client,X-Requested-With
> => all standard headers used by dav clients/browsers (sometime you need to add another one for new client ... so it is good to have a configuration option for additional headers)
>
>
> JM
>
>
> On May 29, 2013, at 4:28 PM, Ken Murchison<murch(a)andrew.cmu.edu> wrote:
>
>> Ján,
>>
>> I'm adding support for CORS requests to my server and I'm wondering if there any response headers that you need/want exposed. I'm not familiar with XMLHttpRequest so I don't know what you have access to normally. Non-simple response headers that I think might be useful:
>>
>> Accept-Ranges
>> Content-Encoding
>> Content-Location
>> DAV
>> ETag
>> Lock-Token
>> Preference-Applied
>> Schedule-Tag
>>
>>
>> Right now, your client works fine without Access-Control-Expose-Headers in the response, but I'm just trying to future-proof my code.
>>
>> --
>> Kenneth Murchison
>> Principal Systems Software Engineer
>> Carnegie Mellon University
--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
Ján,
I'm adding support for CORS requests to my server and I'm wondering if
there any response headers that you need/want exposed. I'm not familiar
with XMLHttpRequest so I don't know what you have access to normally.
Non-simple response headers that I think might be useful:
Accept-Ranges
Content-Encoding
Content-Location
DAV
ETag
Lock-Token
Preference-Applied
Schedule-Tag
Right now, your client works fine without Access-Control-Expose-Headers
in the response, but I'm just trying to future-proof my code.
--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
OK. But you still haven't bumped them up to 0.9 and 0.11 respectively.
Or do you plan to do that when you actually release them?
On 05/29/2013 10:59 AM, Ján Máté wrote:
> These version numbers are "OK" because we have no support for "beta/rc" version comparison. So every beta/rc release is always numbered:
>
> *.42
>
> http://en.wikipedia.org/wiki/42_(number)
>
> :-)
>
>
> JM
>
> On May 29, 2013, at 4:14 PM, Ken Murchison <murch(a)andrew.cmu.edu> wrote:
>
>> On 05/21/2013 04:19 PM, Ján Máté wrote:
>>> Hi everybody,
>>>
>>> new release candidates:
>>>
>>> http://www.inf-it.com/CardDavMATE_0.11rc4.zip
>>> http://www.inf-it.com/CalDavZAP_0.9rc4.zip
>> FYI. The version info in the X-Client request headers isn't up to date.
>>
>> --
>> Kenneth Murchison
>> Principal Systems Software Engineer
>> Carnegie Mellon University
>>
>>
--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
From another thread...
On Mon, 20 May 2013 07:17:56 -0400
Ken Murchison <murch(a)andrew.cmu.edu> wrote:
[snip]
>
> BTW, rather than having the admin specify the path to user principals
> in config.js, you should look into doing your discovery by doing a
> PROPFIND on /.well-known/caldav for DAV:current-user-principal, and
> following any redirects. See http://tools.ietf.org/html/rfc6764
>
What are the odds of this happening?
Thanks,
Jim
--
Note: My mail server employs *very* aggressive anti-spam
filtering. If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://jimsun.LinxNet.com/contact/scform.php>.
Hi everybody,
new release candidates:
http://www.inf-it.com/CardDavMATE_0.11rc4.ziphttp://www.inf-it.com/CalDavZAP_0.9rc4.zip
RC3 -> RC4 changes:
- XML requests cleanup (both clients)
- added "loader" and "error" icons to the CardDavMATE resource list
- CalDavZAP support for additional servers
- removed obsolete functions from CalDavZAP
- fixed problem with delete operation in CardDavMATE (workaround for jQuery 2.0.0 and missing reponseXML property)
- proper processing of addressbook-home-set and calendar-home-set
- updated IANA timezone database + related changes/fixes
- removed TRANSP property from Todos
JM
Actually, my power went out. I will let you know when I'm back up and
running.
On 5/20/2013 9:13 AM, Ján Máté wrote:
> Hi Ken,
>
> looks like you forgot to disable your firewall. I tried to connect
> from two different networks and then also using telnet:
>
> telnet ksmurchison.dyndns.org <http://ksmurchison.dyndns.org> 443
> Trying 76.180.197.142...
> telnet: connect to address 76.180.197.142: Network is unreachable
> telnet: Unable to connect to remote host
>
>
>
> JM
>
>
> On May 20, 2013, at 1:17 PM, Ken Murchison <murch(a)andrew.cmu.edu
> <mailto:murch@andrew.cmu.edu>> wrote:
>
>> OK, the quickest way for me to do this was to give you a test account
>> on my home dev machine:
>
--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
On 05/20/2013 02:17 AM, Ján Máté wrote:
> On May 20, 2013, at 2:50 AM, Ken Murchison <murch(a)andrew.cmu.edu> wrote:
>
>> I applied the caldavzap patch and the client got further along. It sees my calendars but spins trying to load them. The last request that I see if a sync-collection report. I can send telemetry of the request in the morning if you like. I *might* be able to get you access to a test account.
> The fastest way to find the root of the problem is a test account.
OK, the quickest way for me to do this was to give you a test account on
my home dev machine:
host: https://ksmurchison.dyndns.org/dav/principals/user/test01/
passwd: test01
BTW, rather than having the admin specify the path to user principals in
config.js, you should look into doing your discovery by doing a PROPFIND
on /.well-known/caldav for DAV:current-user-principal, and following any
redirects. See http://tools.ietf.org/html/rfc6764
--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
I applied the caldavzap patch and the client got further along. It sees
my calendars but spins trying to load them. The last request that I see
if a sync-collection report. I can send telemetry of the request in the
morning if you like. I *might* be able to get you access to a test account.
On 05/19/2013 05:10 PM, Ján Máté wrote:
> Hi Ken,
>
> XML requests cleanup patches for RC3 (for CardDavMATE there are also few very minor changes):
>
> http://www.inf-it.com/fixes/caldavzap_0.9rc4x.diff
> http://www.inf-it.com/fixes/carddavmate_0.11rc4x.diff
>
> Please report whether these patches solve your problem.
>
>
> JM
>
>
> On May 19, 2013, at 7:51 PM, Ken Murchison <murch(a)andrew.cmu.edu> wrote:
>
>> Just started testing this release, and found the following PROPFIND request:
>>
>> <?xml version="1.0" encoding="utf-8"?><D:propfind xmlns:x3="http://apple.com/ns/ical/" xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav"><D:prop><x3:calendar-color/><D:current-user-privilege-set/><D:max-image-size xmlns:Dd="urn:ietf:params:xml:ns:carddav"/><D:displayname/><D:resourcetype/><D:supported-report-set/><B:supported-calendar-component-set xmlns:B="urn:ietf:params:xml:ns:caldav"/><B:supported-calendar-component-sets xmlns:B="urn:ietf:params:xml:ns:caldav"/><D:sync-token/></D:prop></D:propfind>
>>
>>
>> - You declare the caldav namespace globally (prefixed by 'C'), but then you redeclare it locally in supported-calendar-component-set (prefixed by 'B'). This is confusing my server (which is a bug on my part), but it seems to be extra unnecessary bits on the wire.
>>
>> - There is no standard caldav property named supported-calendar-component-sets (plural). Are you expecting this from some server or is it a typo? v0.9rc3 isn't showing any of my calendars and I'm wondering if this is the reason.
--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University