- From: Bil Corry <bil@corry.biz>
- Date: Wed, 24 Jun 2009 19:42:41 -0500
- To: Adam Barth <w3c@adambarth.com>
- CC: Jonas Sicking <jonas@sicking.cc>, Tyler Close <tyler.close@gmail.com>, Arthur Barstow <Art.Barstow@nokia.com>, public-webapps <public-webapps@w3.org>, Henry Thompson <ht@inf.ed.ac.uk>
Adam Barth wrote on 6/24/2009 6:16 PM:
> On Wed, Jun 24, 2009 at 12:43 PM, Jonas Sicking<jonas@sicking.cc> wrote:
>> As for the "Origin" spec that Adam Barth is working on, I'm not sure
>> that the last draft is published yet, but I believe that the idea is
>> to append the full redirect chain in the Origin header. (hence
>> possibly making it incompatible with the CORS "Origin" meaning that
>> we'll have to use another name).
>
> I've uploaded the latest draft just now:
>
> http://www.ietf.org/internet-drafts/draft-abarth-origin-01.txt
>
> The draft now uses a different header name to avoid conflicting with
> CORS and behaves as Jonas describes.
Why is the spec providing a choice for how to handle redirects?
-----
Whenever a user agent issues an HTTP request to URI /A/ as a result
of an HTTP redirect from URI /B/, the user agent MUST either:
1. set the value of the Sec-From header in the HTTP request to /A/
to "null" (i.e., the character sequence U+006E, U+0075, U+006C,
U+006C),
2. set the value of the Sec-From header in the /A/ request to the
value of the Sec-From header in the /B/ request extended with a
space and the ASCII serialization of the origin of /B/, unless
this would result in the header containing the origin
serialization "null".
-----
Or is it saying that if #2 doesn't apply, then #1?
- Bil
Received on Thursday, 25 June 2009 00:43:28 UTC