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 22:42:42 -0500
Message-ID: <4A42F232.6020307@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 10:09 PM: 
> On Wed, Jun 24, 2009 at 5:42 PM, Bil Corry<bil@corry.biz> wrote:
>> Adam Barth wrote on 6/24/2009 6:16 PM:
>>> 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?
> It's always secure to send null in the header.  In some cases, you
> might have a really long redirect chain and the UA might want to bound
> the header to some length.
>> Or is it saying that if #2 doesn't apply, then #1?
> It says precisely what it says.  The UA MUST either do (1) or (2).
> Sometimes it can't do (2).  In those cases it MUST do (1).  Sometimes
> the UA might be able to do (2) but choose to do (1) anyway.

As written, a conforming UA could choose to always send NULL for redirects, which would be unfortunate.  More concerning though, a conforming UA could choose to always send NULL for *all* HTTP requests.  Might it be better to more strictly define the behavior?

- Bil
Received on Thursday, 25 June 2009 03:43:26 UTC

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