Summary: | CORS handling of 401 response to preflight incorrect (sends the actual POST anyway) | ||
---|---|---|---|
Product: | WebKit | Reporter: | Boris Zbarsky <bzbarsky> |
Component: | Page Loading | Assignee: | Nobody <webkit-unassigned> |
Status: | NEW --- | ||
Severity: | Normal | CC: | abarth, ap, rbuis, youennf |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
URL: | https://bugzilla.mozilla.org/show_bug.cgi?id=778548 |
Description
Boris Zbarsky
2012-07-31 07:50:07 PDT
Looking at public-webapps thread on the topic, there is a reason provided why the CORS draft specification should be changed (IIS with "Classic Application Pool" cannot be configured otherwise), but there is no explanation of why the requirement is necessary. What is the reason for the requirement to reject non-200 responses? Given that the server sends Access-Control-* response header fields, it's not clear to me why it's beneficial. > What is the reason for the requirement to reject non-200 responses?
You could consider reading the thread in the mail archives that made the decision to do so...
Good to know that it has been discussed. Do you have any pointers to that discussion? Not offhand; I'd have to search the archives, just like you... We check that response is 200 in validatePreflightResponse and also pass access-control-preflight-request-invalid-status-400.html and access-control-preflight-request-invalid-status-501.html wpt tests, so I think this can be closed. |