This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Section 2.7.6 "CORS-enabled fetch" executes the CORS "resource sharing check" which fails if the server did not include an Access-Control-Allow-Origin header in the response to the request. This implies that if the user agent did not send an Origin header the resource sharing check will fail and cause the potentially CORS-enabled fetch to taint or fail depending on the mode. In order to clarify the expectation, one possible solution is a statement describing what happens when the Origin header is not sent by the user agent. For example, add a sentence at the end of the first paragraph in section 2.7.6 that states, "If the user agent did not include an Origin header in the request, then the result of the potentially CORS-enabled fetch is success as defined for URL has the same origin as origin."
The expectation would be that it is tainted.
Are you saying a clarification isn't needed or the recommended statement should indicate taint rather than success? > The expectation would be that it is tainted.
Clarification might be nice, although user agents that do not implement CORS seem somewhat broken to me, but you can definitely never get more sharing without CORS than with. It should be either tainted or result in failure.
(In reply to comment #3) > Clarification might be nice, although user agents that do not implement CORS > seem somewhat broken to me, So, why don't we require CORS?
Hmm. What are you more specifically asking about? The user agent always sends a Origin-header if it's doing a CORS-enabled fetch. http://dev.w3.org/html5/spec/urls.html#cors-enabled-fetch So e.g. <img src=cross> will always show you the picture, but it'll be tainted because that's the default - AFAIK it won't send a origin-header because you it's mode is "No CORS". <img src=cross crossorigin>, however, will take a different branch and do a real cross-fetch (either success or fail). <img src=same crossorigin> will go into the first branch, but will restart the algorithm if it's redirected to cross. So all real cross-domain uses should be sending an Origin-header, AFAICS.
The user agent may always send an Origin header when doing a CORS-enabled fetch, but I don't see where the CORS or HTML5 specifications mandate use of that header. I thought there might be reluctance to add such a requirement so the initial proposal was to clarify what happens when the user agent does not send an Origin header. I'm hopeful the editors will acknowledge that lack of clarity and either accept or make counter proposals to the suggestions.
This bug was cloned to create bug 17843 as part of operation convergence.
Silvia, this has been fixed in WHATWG revision r7414.
Fixed by the resolution for bug 17843.
Jumped the gun, needs to be fixed in HTML5 as well.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the Editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the Tracker Issue; or you may create a Tracker Issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy-v2.html Status: Accepted Change Description: https://github.com/w3c/html/commit/f43ac3f0bce8b57f8f7c8891de4093296c049852 Rationale: accepted WHATWG change
Verified changes made to WHATWG HTML Living Standard for this issue also made in W3C HTML5 specification.