Re: HTML5 Origin (aka IETF Origin draft)

Great, thanks for the explanation.

- Bil


Adam Barth wrote on 4/11/2009 2:48 PM: 
> Ah, I see.  Yes.  The algorithm in Section 2 is designed to be
> re-usable in other specs.  For example, HTML 5 could reference this
> spec.  Implementations might need to have funny behaviors for things
> like file:// URLs.  Letting them return an implementation defined
> value here (and supporting it in Section 3) helps them do that.
> 
> Adam
> 
> 
> On Sat, Apr 11, 2009 at 12:26 PM, Bil Corry <bil@corry.biz> wrote:
>> I wasn't clear, apologies.  I'm confused why Section 2 Step 3 requires the UA to return an implementation-defined value for Origin, then turn around and required it be sent as "null" when it's sent to the server (Section 4.2 Step 1).  If it will be sent as "null", then why not just have Section 2 Step 3 skip the implementation-defined value and instead set it to "null"?  Or is there another use client-side for the implementation-defined value?
>>
>>
>> - Bil
>>
>>
>> Adam Barth wrote on 4/11/2009 11:46 AM:
>>> I don't understand what you're requesting.  The spec already says that
>>> in Section 4.2, step 1.  Requirement 1 of paragraph 3 of section 5 is
>>> to ensure that all POST requests (including those generated by the
>>> browser itself) contain a sensible Origin header.
>>>
>>> Adam
>>>
>>>
>>> On Sat, Apr 11, 2009 at 5:27 AM, Bil Corry <bil@corry.biz> wrote:
>>>> But if it never gets sent to the server, is there some other purpose for a UA to calculate the Origin string?  Couldn't the draft simply state that to calculate the Origin, if it isn't a (scheme, host, port) tuple, it's "null" since that's all that gets sent anyhow?
>>>>
>>>> - Bil
>>>>
>>>> Adam Barth wrote on 4/10/2009 1:01 PM:
>>>>> This is to support things like data URLs that can't be represented as
>>>>> a (scheme, host, port) tuple.
>>>>>
>>>>> Adam
>>>>>
>>>>>
>>>>> On Thu, Apr 9, 2009 at 9:48 AM, Bil Corry <bil@corry.biz> wrote:
>>>>>> I wanted to clarify something in the IETF Origin draft[1], which is now going to serve as the basis for HTML5's Origin.
>>>>>>
>>>>>> Section 5 requires that when a user agent provides the Origin header, it must either send "null" or the ASCII serialization of the origin.  ASCII serialization (and Unicode serialization) stipulates that if an origin is not a scheme/host/port tuple, then it must return "null".  Section 2 allows implementations to define other types of origins in addition to the scheme/host/port tuple.  So my question is, if a user agent defines another type of origin, but is required to send "null" for it in the Origin header, is there some other use for defining other types of origins?
>>>>>>
>>>>>>
>>>>>> - Bil
>>>>>>
>>>>>> [1] http://www.ietf.org/internet-drafts/draft-abarth-origin-00.txt
>>>>>>
>>
> 
>

Received on Saturday, 11 April 2009 21:52:06 UTC