W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: [cors] TAG request concerning CORS & Next Step(s)

From: Bil Corry <bil@corry.biz>
Date: Wed, 24 Jun 2009 19:42:41 -0500
Message-ID: <4A42C801.3050408@corry.biz>
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,

   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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:54 UTC