Re: HTML5 Origin (aka IETF Origin draft)
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 b...@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
Re: HTML5 Origin (aka IETF Origin draft)
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 b...@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 b...@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 b...@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
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 b...@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 b...@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 b...@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
Re: HTML5 Origin (aka IETF Origin draft)
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 b...@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
HTML5 Origin (aka IETF Origin draft)
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
