[draft-abarth-origin-03] feedback

[Anne van Kesteren-2]

The origin production does not need 1*WSP as far as I know. Or is this how  
headers are supposed to be defined per 2616bis?

The origin-list production should use SP and not 1*WSP. I'd like to keep  
the format as simple as possible.

I think it should be a MUST and not a MAY on consecutive origins. (Be  
conservative in what you send and all.)

I also think the draft should make a requirement for one of the two  
options regarding redirects and not leave it open.

Is the idea that CORS will reference this draft in the end? Currently I  
have registered the Origin header with IANA.


--
Anne van Kesteren
http://annevankesteren.nl/

[Adam Barth-5]

On Tue, Sep 29, 2009 at 5:22 AM, Anne van Kesteren <annevk@...> wrote:
> The origin production does not need 1*WSP as far as I know. Or is this how
> headers are supposed to be defined per 2616bis?

Fixed.

> The origin-list production should use SP and not 1*WSP. I'd like to keep the
> format as simple as possible.

Fixed.

> I think it should be a MUST and not a MAY on consecutive origins. (Be
> conservative in what you send and all.)

Fixed.

> I also think the draft should make a requirement for one of the two options
> regarding redirects and not leave it open.

I haven't changed this because the draft always lets the client send
the value "null".  This is a fail-safe so that the client can always
proceed even if it forgets what the origin ought to be.  Here you
should imagine some code close to the wire that adds an "Origin: null"
header if the request somehow got there without an Origin header.

> Is the idea that CORS will reference this draft in the end? Currently I have
> registered the Origin header with IANA.

I'd be more than happy if CORS referenced this draft.  Let me know if
there's anything I can do to make this easier for you.

Adam

[Adam Barth-5]

Posted: http://www.ietf.org/id/draft-abarth-origin-04.txt

Adam


On Tue, Sep 29, 2009 at 9:53 AM, Adam Barth <w3c@...> wrote:

> On Tue, Sep 29, 2009 at 5:22 AM, Anne van Kesteren <annevk@...> wrote:
>> The origin production does not need 1*WSP as far as I know. Or is this how
>> headers are supposed to be defined per 2616bis?
>
> Fixed.
>
>> The origin-list production should use SP and not 1*WSP. I'd like to keep the
>> format as simple as possible.
>
> Fixed.
>
>> I think it should be a MUST and not a MAY on consecutive origins. (Be
>> conservative in what you send and all.)
>
> Fixed.
>
>> I also think the draft should make a requirement for one of the two options
>> regarding redirects and not leave it open.
>
> I haven't changed this because the draft always lets the client send
> the value "null".  This is a fail-safe so that the client can always
> proceed even if it forgets what the origin ought to be.  Here you
> should imagine some code close to the wire that adds an "Origin: null"
> header if the request somehow got there without an Origin header.
>
>> Is the idea that CORS will reference this draft in the end? Currently I have
>> registered the Origin header with IANA.
>
> I'd be more than happy if CORS referenced this draft.  Let me know if
> there's anything I can do to make this easier for you.
>
> Adam
>

[Julian Reschke]

Anne van Kesteren wrote:
> The origin production does not need 1*WSP as far as I know. Or is this
> how headers are supposed to be defined per 2616bis?
> ...

It needs to specify the whitespace, unless it invokes the special ABNF
semantics from RFC2616 that use implied LWS (which I don't think it does).

 > ...

BR, Julian

[Adam Barth-5]

On Tue, Sep 29, 2009 at 10:13 AM, Julian Reschke <julian.reschke@...> wrote:
> Anne van Kesteren wrote:
>> The origin production does not need 1*WSP as far as I know. Or is this how
>> headers are supposed to be defined per 2616bis?
>> ...
>
> It needs to specify the whitespace, unless it invokes the special ABNF
> semantics from RFC2616 that use implied LWS (which I don't think it does).

We don't want to use the implied whitespace because it screws up the
serialized-origin production.  What magically sequence of characters
should I include in this production to make this header behave like a
normal header?

  origin            = "origin" ":" [ "null" / origin-list ]

Thanks,
Adam

[Julian Reschke]

Adam Barth wrote:

> On Tue, Sep 29, 2009 at 10:13 AM, Julian Reschke <julian.reschke@...> wrote:
>> Anne van Kesteren wrote:
>>> The origin production does not need 1*WSP as far as I know. Or is this how
>>> headers are supposed to be defined per 2616bis?
>>> ...
>> It needs to specify the whitespace, unless it invokes the special ABNF
>> semantics from RFC2616 that use implied LWS (which I don't think it does).
>
> We don't want to use the implied whitespace because it screws up the
> serialized-origin production.  What magically sequence of characters
> should I include in this production to make this header behave like a
> normal header?
>
>   origin            = "origin" ":" [ "null" / origin-list ]

I think you need

origin            = "origin" ":" OWS [ "null" / origin-list ] OWS

where OWS is defined in
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#rfc.section.1.2.2>
as

   OWS            = *( [ obs-fold ] WSP )
                  ; "optional" whitespace
   obs-fold       = CRLF

BR, Julian

[Adam Barth-5]

On Tue, Sep 29, 2009 at 10:33 AM, Julian Reschke <julian.reschke@...> wrote:
> I think you need
>
> origin            = "origin" ":" OWS [ "null" / origin-list ] OWS

Thanks.  Fixed in http://www.ietf.org/staging/draft-abarth-origin-05.txt

I'll add the citation when I do a citation pass.

Adam

[Adam Barth-5]

On Tue, Sep 29, 2009 at 10:42 AM, Adam Barth <w3c@...> wrote:
> On Tue, Sep 29, 2009 at 10:33 AM, Julian Reschke <julian.reschke@...> wrote:
>> I think you need
>>
>> origin            = "origin" ":" OWS [ "null" / origin-list ] OWS
>
> Thanks.  Fixed in http://www.ietf.org/staging/draft-abarth-origin-05.txt

Oops: http://www.ietf.org/id/draft-abarth-origin-05.txt

Adam

[Ian Hickson]

On Tue, 29 Sep 2009, Adam Barth wrote:
>
> Posted: http://www.ietf.org/id/draft-abarth-origin-04.txt

I have an outstanding e-mail in my HTML5 pile for the "TODO: Check that we
handle IPv6 literals correctly." -- did I ever forward that to you?

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Adam Barth-5]

On Tue, Sep 29, 2009 at 3:17 PM, Ian Hickson <ian@...> wrote:
> On Tue, 29 Sep 2009, Adam Barth wrote:
>>
>> Posted: http://www.ietf.org/id/draft-abarth-origin-04.txt
>
> I have an outstanding e-mail in my HTML5 pile for the "TODO: Check that we
> handle IPv6 literals correctly." -- did I ever forward that to you?

Yeah.  That's on my list.

Adam

[Anne van Kesteren-2]

On Tue, 29 Sep 2009 18:53:20 +0200, Adam Barth <w3c@...> wrote:
>> The origin-list production should use SP and not 1*WSP. I'd like to  
>> keep the format as simple as possible.
>
> Fixed.

It is now 1*SP. Since the requirement on user agents is a single space I  
think just SP would be better.


>> I also think the draft should make a requirement for one of the two  
>> options regarding redirects and not leave it open.
>
> I haven't changed this because the draft always lets the client send
> the value "null".  This is a fail-safe so that the client can always
> proceed even if it forgets what the origin ought to be.  Here you
> should imagine some code close to the wire that adds an "Origin: null"
> header if the request somehow got there without an Origin header.

Ok.


>> Is the idea that CORS will reference this draft in the end? Currently I  
>> have registered the Origin header with IANA.
>
> I'd be more than happy if CORS referenced this draft.  Let me know if
> there's anything I can do to make this easier for you.

It would be nice if there was a production item for 'OWS [ "null" /  
origin-list ] OWS' so that I can use that for Access-Control-Allow-Origin.  
I.e. origin-value or some such.


--
Anne van Kesteren
http://annevankesteren.nl/

[Anne van Kesteren-2]

On Fri, 02 Oct 2009 11:58:54 +0200, Anne van Kesteren <annevk@...>  
wrote:
>>> Is the idea that CORS will reference this draft in the end? Currently  
>>> I have registered the Origin header with IANA.
>>
>> I'd be more than happy if CORS referenced this draft.  Let me know if
>> there's anything I can do to make this easier for you.
>
> It would be nice if there was a production item for 'OWS [ "null" /  
> origin-list ] OWS' so that I can use that for  
> Access-Control-Allow-Origin. I.e. origin-value or some such.

I also think it would make sense if the draft was more upfront about that  
it also serves as a definition of the origin concept and related concepts  
(serializations and comparison). Those concepts are useful outside the  
scope of the Origin header as well. Maybe the draft should be named "Web  
Origin Concept" or something...


--
Anne van Kesteren
http://annevankesteren.nl/

[Adam Barth-5]

On Fri, Oct 2, 2009 at 2:58 AM, Anne van Kesteren <annevk@...> wrote:
> On Tue, 29 Sep 2009 18:53:20 +0200, Adam Barth <w3c@...> wrote:
>>>
>>> The origin-list production should use SP and not 1*WSP. I'd like to keep
>>> the format as simple as possible.
>>
>> Fixed.
>
> It is now 1*SP. Since the requirement on user agents is a single space I
> think just SP would be better.

Fixed.

>>> Is the idea that CORS will reference this draft in the end? Currently I
>>> have registered the Origin header with IANA.
>>
>> I'd be more than happy if CORS referenced this draft.  Let me know if
>> there's anything I can do to make this easier for you.
>
> It would be nice if there was a production item for 'OWS [ "null" /
> origin-list ] OWS' so that I can use that for Access-Control-Allow-Origin.
> I.e. origin-value or some such.

Done.  origin-list-or-null is the name.

If you like, I can post the new version.  Left to my own devices, I'll
wait for TPAC so we can resolve the comma / space issue.

Adam