This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The spec needs to specify how timeout should behave when there is Preflight OPTIONS request. It seemed logical to assume xhr.timeout = timeout (OPTIONS + ACTUAL) request The way browsers implement is non intuitive. Say I set timeout as 1000 (1sec). The browser sets 1000ms timeout for OPTIONS and 1000ms timeout for ACTUAL request. Clarifying that in the spec would enable browsers to implement the right way.
It seems what browsers are doing here does violate the specification as written. I wonder if a redirect resets the timeout as well... On a different note, could you perhaps indicate whether https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/thread.html#msg646 would be of any help? (Caching of CORS preflights for an entire origin when no credentials are involved.) It's pretty hard to get feedback from users of CORS.
(In reply to Anne from comment #1) > It seems what browsers are doing here does violate the specification as > written. I wonder if a redirect resets the timeout as well... You guessed it right. Redirect does reset the timeout. > > On a different note, could you perhaps indicate whether > https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/thread. > html#msg646 would be of any help? (Caching of CORS preflights for an entire > origin when no credentials are involved.) It's pretty hard to get feedback > from users of CORS. Caching of CORS preflight even for a single resource will improve performance by a great deal. Some of the use cases are posting data to a log server or sending resumable /chunked uploads to say Google cloud storage or Amazon S3. Your proposal on caching for entire origin is a great idea. But I have to agree with Brad (https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0650.html) especially this part: On disadvantages of headers: 1) Individual resources declaring policy for an entire origin can be problematic and difficult to manage. I will give some more thought and comment on your CORS performance thread.
I realize it's been two years, but I finally created tests for this and they show that the problem does not appear for redirects, just CORS preflights and only in Chrome: https://github.com/w3c/web-platform-tests/pull/5104. I'm going to close this bug as this is not a problem with the standard. I'll also file a bug on Chrome.