User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/534.3 (KHTML, like Gecko) Chrome/6.0.472.59 Safari/534.3 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:184.108.40.206) Gecko/20100914 Firefox/3.6.10 (.NET CLR 3.5.30729) When you submit cross-domain PROPFIND request using XmlHttpRequest to a server that is using Basic authentication the request silently fails. No login dialog is displayed. The same issue if the server is using Integrated Windows Authentication. For servers with Digest or anonymous authentication the request works with no problem. Cross-domain GET and POST requests work fine. Reproducible: Always Steps to Reproduce: 1. Go to http://www.ajaxfilebrowser.com/?CrossDomainDemo 2. Enter url of the WebDAV server that is using Basic authentication in 'WebDAV Server Url' field. For example this one: http://www.ithit.com:8044/ Login: User1 Password: pwd 3. Click "Connect" button. Using a debugging proxy you can find that preflight OPTIONS request is being sent but no login dialog is displayed and no PROPFIND request is sent. Actual Results: No login dialog displayed, request failed. Expected Results: Login dialog is displayed. PROPFIND is submitted to server. Chrome browser work with Basic, Digest and Integrated windows with no problem.
So in this case the server responds to the OPTIONS request with a 401, right? The CORS spec recently changed how 4xx response codes need to be handled; this is a duplicate of the bug on us making that change to our code...
Actually, for preflight requests we agreed that no credentials are to be included in the request. So this would be a bug in Chrome, I think.
The preflight doesn't include credentials. But then the server responds with a 401, is the intent not to include credentials for the 401 at that point? The spec goes out of its way now to say that 4xx errors are not immediately fatal...
Actually, wouldn't it make the most sense to say that the OPTIONS response has to be a 2xx/1xx response? It seems very strange to just treat a 200 and a 404 response from the OPTIONS request completely identical.
Prolly. Email the list?
Created attachment 477373 [details] [diff] [review] WIP This should work but needs tests. Attaching so I don't loose it. Note that I think the spec should require a 2xx response to OPTIONS requests, and have implemented this strategy. I also raised the issue on the list.
(In reply to comment #6) > Created attachment 477373 [details] [diff] [review] > WIP > > This should work but needs tests. Attaching so I don't loose it. > > Note that I think the spec should require a 2xx response to OPTIONS requests, > and have implemented this strategy. I also raised the issue on the list. Why require a 2xx for OPTIONS when other methods require authentication? I think it's totally plausible that the server responds with 401 to *all* unauthenticated requests (actually, authentication checks may happen before even looking at the method).
Also, out of curiosity: why is there a preflight request for PROPFIND anyway? CORS, 6.1.5.: "To protect resources against cross-origin access with methods that have side effects an preflight request is made to ensure that the resource is ok with the request." RFC 4918, 9.1.: "...This method is both safe and idempotent (see Section 9.1 of [RFC2616])..."
> Also, out of curiosity: why is there a preflight request for PROPFIND anyway? Because CORS says to do so. > CORS, 6.1.5.: The text you're quoting is informative. The normative text is that if there is no method cache match for the method and the method is not a simple method you have to preflight. In this case, there is no preflight result cache entry (and in fact I don't think we have a preflight cache) and the definition of "simple method" in CORS is: A method is said to be a simple method if it is a case-sensitive match for one of the following: GET HEAD POST In other words, it seems that what CORS really uses preflights for is "check before doing anything weird", not what it claims at the top of 6.1.5.
Please stick to one issue per bug. And spec discussions are better held on the Webapps mailing list. No decisions can or will be made here regarding changing the spec.
I agree that all requests including OPTIONS request must be authenticated. In case OPTIONS requests are unauthenticated (so the server never replies with 4xx code) it will have following disadvantages: 1. Changes to server code will be required. In many cases we can add headers required by CORS, but not to change the code on server side. 2. If OPTIONS request is unauthenticated this probably is a security risk. The user can use it to test folders existence.
Created attachment 479707 [details] [diff] [review] Patch to fix This updates us to spec for a range of smaller issues: * Don't make requests fail for http-errors. I.e. 404 responses are still forwarded. Note that http-errors in the preflight response still results in a failed request (this also allowed me to remove some media-element code which whitelisted some error codes) * If a HEAD request is preflighted, don't require access-control-allow-methods to include 'head' * Remove special handling for "Content-Type" header on POST requests. Instead simply treat "content-type" as a preflighted header if it doesn't have one of the white-listed values. * Change tests to make it easier to check that both failing conditions and succeeding conditions for the same feature are tested. I.e. rather than having all denying tests listed together, and all succeeding tests listed together, annotate on each test if it's expected to be denying or succeeding, and reorder them.
Created attachment 479708 [details] [diff] [review] Add support for access-control-expose-headers The CORS spec has changed in one more way, it has grown a new feature. It is now possible for the server to whitelist headers which the requesting site can access using the usual XMLHttpRequest.getResponseHeader. Previously only a small whitelist of headers could be read using this API, now additional headers can be whitelisted by the server using the "access-control-expose-headers" response header.
There is a discussion about similar CORS issue in Safari/WebKit: https://bugs.webkit.org/show_bug.cgi?id=45943
Eeep, forgot to pull this in to beta7 before checking in. Since it's changing some behavior towards web pages I figured it was better than not to land this for beta7. http://hg.mozilla.org/mozilla-central/rev/a5b5aeb0b4f0 http://hg.mozilla.org/mozilla-central/rev/9df5d817b35b
I assume beta7 is the Firefox version 3.7? Are there any information when it will be released?
Beta 7 is Firefox 4 beta 7. It'll likely be released in a matter of a week or two. This is not the place to ask though, the mozilla.dev.planning newsgroup is a better place.
Looking through this it appears that the addition of "Access-Control-Expose-Header" is the thing that needs documenting here; everything else appears to just be bug fixes. Is that forrect? I've documented access-control-expose-header here: https://developer.mozilla.org/En/HTTP_access_control#Access-Control-Expose-Header Please have a look and let me know if that's correct.
We should also mention that "text/plain", "application/x-www-form-urlencoded" and "multipart/form-data" encoded data can be sent cross-site without requiring a preflight. (The last is particularly useful together with FormData). Previously only "text/plain" was allowed to be sent cross site without preflight.
Added a note about the encodings here: https://developer.mozilla.org/En/HTTP_access_control#Preflighted_requests