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 >>>>> > >
