- From: Bil Corry <bil@corry.biz>
- Date: Wed, 24 Jun 2009 22:42:42 -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 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