-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CO Redirect in the face of CORs may not be correct in specs #32
Comments
Related FF bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1280692. As noted by Cristoph in that thread, we have some confusion between various specs: https://www.w3.org/TR/cors/#cors-api-specification-redirect
https://fetch.spec.whatwg.org/#http-fetch
Stepping back, in term of actual functional requirements for sendBeacon: we set credentials mode to "include", mode to "cors", and redirect mode is set to "follow" by default. The intent behind these flags is to allow sites to shift away from using image pings.. which provide same semantics, but require that sites block the browser from unloading and cancelling such requests. In practice, the redirects in particular appear to be a fairly common case: the request is bounced through different analytics services, etc. The reason this came up as an issue is that after running some trials the telemetry showed that browsers that block redirects have a lower delivery rate / worse performance than image pings.
There is also the question of whether the Set-Cookie's are processed. If we want to match the existing image-beacon use case (which, I think we should), we need to follow redirects and allow set-cookies to be processed. We don't care for the response; we don't allow access to the response body. /cc @annevk |
Upon reading and re-reading both Beacon and Fetch, this could be solvable within the Beacon spec (assuming we believe this is correct beahvior for sendBeacon). We could use 'cors' for Blob and 'no-cors' for other payloads.
|
~related: #10 (comment)
As a sanity check, how would this interact with credentials mode? We set it to "include" for Beacon and if we combine that with "no-cors" for non-Blob payloads... Set-Cookie's are processed? |
Yes, they would be, but using |
@annevk any tips on checklist of edge cases to consider? :) re, set-cookies: what's confusing me is the last example in 4.2.6, which shows a fetch request with credentials set to include and (default) mode of no-cors. If I'm reading that correctly, in order for Set-Cookie to be processed, the origin would have to return both the ACAO and the ACAC headers? If so, that's basically a non-starter for replacing the current image beacons. As a separate question: can we clarify the behavior for mode=cors and redirects? Does each redirect need to provide the various ACA* headers, or only the destination? |
None of the examples there use "no-cors". The default for |
Each redirect needs to opt-in, otherwise you have information leakage. |
A request has an associated mode, which is "same-origin", "cors", "no-cors", "navigate", or "websocket". Unless stated otherwise, it is "no-cors". From: https://fetch.spec.whatwg.org/#concept-request-mode.. I'm probably missing something obvious? |
Yeah, |
Ilya created a very useful test at:
http://output.jsbin.com/suxagi/latest/quiet
It demonstrates a Cross Origin Redirect encountering CORs in Firefox/Microsoft Edge which is correct per Fetch spec at time of this issue being created. HTTP Fetch 5.3, point 5.4 which instructs a network error to occur per the current Beacon/Fetch specs.
Chrome does not follow the current specs and allows the redirect.
There are some large web properties evaluating a move to sendBeacon and this issue was encountered by them in private communication with Ilya and he raised it with each browser vendor. As it seems to require a spec update, I've moved the issue to the spec issues list.
The question for the specs is this:
Is the intent of the ACAO header to protect only the body? (Which seems to require a Beacon/Fetch spec update)
OR is it intended to protect redirects as well? (As written)
The text was updated successfully, but these errors were encountered: