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 Murchisonmurch@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