Re: Do we need to rename the Origin header?

Adam Barth wrote on 6/24/2009 8:58 PM: 
> On Wed, Jun 24, 2009 at 5:48 PM, Bil Corry<bil@corry.biz> wrote:
>> Adam Barth wrote on 6/20/2009 6:25 PM:
>>> On Sat, Jun 20, 2009 at 12:57 PM, Bil Corry<bil@corry.biz> wrote:
>>>> I've lost track, is this still something being considered?
>>> I should have an updated draft posted soon.
>> I'm not clear with the new draft if it now allows Sec-From for same-origin GET requests, it says:
> 
> I'll respond to everyone's feedback in as time permits (probably in
> the next couple of days).
> 
> To answer you question, the draft has always allowed the header to be
> send for same-origin GETs.  The difference is we now require it for
> participating user agents.  Also, the draft has always allowed the
> user agent to send the value "null."  The new spec introduces the term
> "privacy-sensitive" as a hook so that other specs can easily control
> when to send null or a non-null value.
> 
>> But it doesn't define "privacy-sensitive".  It does say:
> 
> This is for application-level specs, like HTML 5, to define.
> 
>> So presumably a GET request to the same origin isn't a "privacy-sensitive" request, but I'm just double-checking.  I think explicitly defining or referencing what constitutes a "privacy-sensitive" request would greatly improve the draft.
> 
> We can't determine which requests are privacy-sensitive at this layer.
>  For example, HTML 5 might wish to define requests generated from <a>
> elements as privacy sensitive but requests generated from <form>
> elements as not privacy sensitive.

Continuing your example, if XHTML defines requests from <form> as privacy-sensitive, then the UA will have two different behaviors for Sec-From, depending on if it's rendering HTML5 or XHTML?


- Bil

Received on Thursday, 25 June 2009 03:51:14 UTC