CORS: Cross-domain PROPFIND XHR request for servers with Basic authentication does not work.




7 years ago
4 years ago


(Reporter: Vladimir Lichman, Assigned: sicking)



Windows Vista

Firefox Tracking Flags

(blocking2.0 beta7+)




(2 attachments, 1 obsolete attachment)



7 years ago
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: 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
2. Enter url of the WebDAV server that is using Basic authentication in 'WebDAV Server Url' field. For example this one:
 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.

Comment 1

7 years ago
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...
Whiteboard: DUPEME
Assignee: nobody → jonas
blocking2.0: --- → final+

Comment 2

7 years ago
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.

Comment 3

7 years ago
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.

Comment 5

7 years ago
Prolly. Email the list?
Created attachment 477373 [details] [diff] [review]

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.

Comment 7

7 years ago
(In reply to comment #6)
> Created attachment 477373 [details] [diff] [review]
> 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).

Comment 8

7 years ago
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])..."

Comment 9

7 years ago
> 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:

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.

Comment 11

7 years ago
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.
Attachment #477373 - Attachment is obsolete: true
Attachment #479707 - Flags: review?(jst)
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.
Attachment #479708 - Flags: review?(jst)
Ever confirmed: true
Whiteboard: DUPEME
Duplicate of this bug: 596634


7 years ago
Attachment #479707 - Flags: review?(jst) → review+


7 years ago
Attachment #479708 - Flags: review?(jst) → review+

Comment 15

7 years ago
There is a discussion about similar CORS issue in  Safari/WebKit:
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.
blocking2.0: final+ → beta7+
Last Resolved: 7 years ago
Resolution: --- → FIXED
Blocks: 503200

Comment 17

7 years ago
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 newsgroup is a better place.
Keywords: dev-doc-needed
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:

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:
Keywords: dev-doc-needed → dev-doc-complete
Component: DOM: Other → DOM
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.