Bug 16841 - Expected use of Origin HTTP header
Summary: Expected use of Origin HTTP header
Status: CLOSED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Silvia Pfeiffer
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-24 17:52 UTC by Patrick Ladd
Modified: 2012-10-15 23:54 UTC (History)
9 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Ladd 2012-04-24 17:52:20 UTC
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."
Comment 1 Anne 2012-04-24 20:23:48 UTC
The expectation would be that it is tainted.
Comment 2 Patrick Ladd 2012-04-24 20:35:55 UTC
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.
Comment 3 Anne 2012-04-24 20:39:41 UTC
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.
Comment 4 Mark Vickers 2012-04-26 19:22:03 UTC
(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?
Comment 5 Odin Hørthe Omdal 2012-05-08 12:47:45 UTC
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.
Comment 6 Patrick Ladd 2012-05-10 23:40:33 UTC
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.
Comment 7 contributor 2012-07-18 07:01:25 UTC
This bug was cloned to create bug 17843 as part of operation convergence.
Comment 8 Edward O'Connor 2012-10-02 23:27:33 UTC
Silvia, this has been fixed in WHATWG revision r7414.
Comment 9 Patrick Ladd 2012-10-09 19:14:37 UTC
Fixed by the resolution for bug 17843.
Comment 10 Patrick Ladd 2012-10-09 22:43:01 UTC
Fixed by the resolution for bug 17843.
Comment 11 Patrick Ladd 2012-10-09 22:52:43 UTC
Jumped the gun, needs to be fixed in HTML5 as well.
Comment 12 Silvia Pfeiffer 2012-10-14 12:33:11 UTC
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
Comment 13 Patrick Ladd 2012-10-15 23:54:58 UTC
Verified changes made to WHATWG HTML Living Standard for this issue also made in W3C HTML5 specification.