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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>>>>> >> > >
