Subject: Comments on the HTTP Sec-From Header (draft-abarth-origin)

From: Mark Nottingham <[email-masked]>
Date: Thu, 9 Jul 2009 11:39:06 +1000

A few notes, mostly editorial.

* It would be helpful to give more information about the use case and  
applicability of this header in the Introduction.

* Likewise, it would be very helpful if it was positioned in relation  
to Referer and Origin, perhaps in an Appendix.

* Section 2 talks about applying the IDNA ToASCII algorithm to parts  
of a URI. This doesn't make sense; perhaps you mean IRI?

* The /variable/ syntax is distracting.

* Specifying RFC2119 requirements as "Implementations MUST use the  
following algorithm..." isn't good practice, as discussed previously.  
E.g., section 2 would be better specified as:

---8<---

2. Origin

The origin is used to [whatever function this component has; it isn't  
yet explained].

Usually, an origin is a tuple of (scheme, host, port). However,  
implementations MAY define other types of origins; for example, user  
agents could have a concept of a globally unique origin, or a  
certificate-based origin. However, computation and use of such origins  
are outside the scope of this specification.

An origin is computed for a given URI [RFC3986].  [ or is this really  
an IRI? see above ]

If the URI cannot be parsed, does not contain an authority component  
(see RFC3986 Section 3.2), or is a relative reference ([RFC3986]  
Section 4.2) the origin MUST NOT be computed.

If the URI's scheme is not supported by the implementation, the origin  
MUST NOT be computed. If the scheme is 'file', then an implementation  
MAY refuse to compute an origin as well [ this needs to change to  
reflect the purpose of this clause ].

When computing an origin, the host MUST be converted to lowercase. If  
there is no port in the URI, it MUST be considered to be the default  
port for the scheme.

--->8---

* Just FYI, IDNA is currently being revised; see <http://tools.ietf.org/wg/idnabis/ 
 >.

* There's a lot instances of 'implementation-defined value' in prose,  
but no context of what these are, how they might be used, etc.

* Section 5 places requirements on User Agents. I'm assuming you mean  
UAs that conform to *this* specification; if so, it would be good to  
spell this out (either here or in a conformance criteria section).

* The header field-value is defined as containing LWS characters.  
There isn't a reference for that rule, and FYI that form is being  
deprecated by HTTPbis; it would probably be better to say one or more  
whitespace characters. Another option would be to make it a comma- 
separated list, to pull it in line with the definitions of other HTTP  
headers.

--
Mark Nottingham     http://www.mnot.net/

---

From: Adam Barth <[email-masked]>
Date: Wed, 8 Jul 2009 22:58:22 -0700

Thank you for your comments.

> applicability of this header in the Introduction.

Will do.

> * Likewise, it would be very helpful if it was positioned in relation to
> Referer and Origin, perhaps in an Appendix.

Will do.

> * Section 2 talks about applying the IDNA ToASCII algorithm to parts of a
> URI. This doesn't make sense; perhaps you mean IRI?

I'm a bit unclear on the difference between URIs and IRIs.  Is there
are  a good reference you could point me to?

> * The /variable/ syntax is distracting.

Is there a standard way of distinguishing variables from
non-variables?  In non-ASCII specs, I've seen italics used for this
purpose.

> * Specifying RFC2119 requirements as "Implementations MUST use the following
> algorithm..." isn't good practice, as discussed previously. E.g., section 2
> would be better specified as:

The preference for one or the other seems to vary by community.  The
algorithmic parts of the spec originated from HTML 5, which is largely
written in that style.  I can change to the declarative style if Ian
doesn't think that will cause a problem for HTML 5.

> * Just FYI, IDNA is currently being revised; see
> <http://tools.ietf.org/wg/idnabis/>.

I also have little understanding of IDNA.

> * There's a lot instances of 'implementation-defined value' in prose, but no
> context of what these are, how they might be used, etc.

Maybe some examples would clarify the situation?  Ian has asked me to
specify what these actually are, which is another alternative.

> * Section 5 places requirements on User Agents. I'm assuming you mean UAs
> that conform to *this* specification; if so, it would be good to spell this
> out (either here or in a conformance criteria section).

Will do.

> * The header field-value is defined as containing LWS characters. There
> isn't a reference for that rule, and FYI that form is being deprecated by
> HTTPbis; it would probably be better to say one or more whitespace
> characters. Another option would be to make it a comma-separated list, to
> pull it in line with the definitions of other HTTP headers.

My understanding is that using a comma-separated list would change the
semantics because of header coalescing.  Saying "whitespace" seems
less precise than LWS.  Is whitespace defined precisely somewhere in
HTTPbis that I can reference?

Adam

---

From: Ian Hickson <[email-masked]>
Date: Thu, 9 Jul 2009 07:06:34 +0000 (UTC)

On Wed, 8 Jul 2009, Adam Barth wrote:
> 
> I'm a bit unclear on the difference between URIs and IRIs.  Is there are 
> a good reference you could point me to?

You probably want to just refer to DanC's Web Addresses draft (since I 
believe we need to be able to handle non-conforming URIs here too, e.g. 
the page "http://www.example.com/%" still has an origin, but that's 
neither a URI nor an IRI), but I hear there's work to merge that with 
IRIs, so it's unclear exactly what the state is of that. I'm not sure what 
I'm going to do with HTML5 regarding this -- I guess if this isn't 
resolved by October (last call) I'll just temporarily put the definitions 
back into HTML5, just so we have a clear place that defines the parsing.

> Is there a standard way of distinguishing variables from non-variables?  
> In non-ASCII specs, I've seen italics used for this purpose.

(If you find an answer to this please let me know; I've got the same 
problem in the WebSocket I-D.)

> doesn't think that will cause a problem for HTML 5.

If you use the style "the algorithm is: 1. do this. 2. do that." I can 
invoke it with a "must" from HTML5 to get the right normative conformance 
criteria for testing purposes, so if this helps you resolve issues and 
move the draft forward, go for it.

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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 09 Jul 2009 09:16:17 +0200

Ian Hickson wrote:
> ...
> ...

No, there is no standard way in IETF documents to do so. As far as I can 
tell, decorating terms with "_" or "/" is uncommon and is unlikely to be 
accepted by the RFC Editor.

Best regards, Julian

---

From: Ian Hickson <[email-masked]>
Date: Thu, 9 Jul 2009 07:18:34 +0000 (UTC)

> accepted by the RFC Editor.

What should we do instead?

---

From: Julian Reschke <[email-masked]>
Date: Thu, 09 Jul 2009 09:23:06 +0200

> What should we do instead?

Write the text in a way that it's understandable without decorations.

(I did not invent that format, nor do I like it, but this is the only 
answer I have)

BR, Julian

---

From: Ian Hickson <[email-masked]>
Date: Thu, 9 Jul 2009 07:33:57 +0000 (UTC)

> Write the text in a way that it's understandable without decorations.

I originally did, but then I had to convert it to plain text. :-(

Oh well.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 9 Jul 2009 17:43:17 +1000

Try defining new terms to be unique and distinguished; hyphenation  
comes in handy for this (e.g., origin-URI, host-value, port-value).

Explicitly importing (A)BNF terms from other specs and defining new  
ones helps distinguish them as well; however, it looks like most of  
this spec is defining an abstract model, not syntax (I wonder if it  
could be refactored that way, however).

I agree it's not an ideal situation.

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 12 Jul 2009 11:01:34 +1000

On 09/07/2009, at 3:58 PM, Adam Barth wrote:
>> There
> semantics because of header coalescing.

How so? I.e., does this:

Sec-From: a.com b.com, c.com d.com

place an semantic significance on the split between a/b and c/d?

>  Saying "whitespace" seems

Best thing do to would be to reference WS in RFC5234.

---

From: Adam Barth <[email-masked]>
Date: Sun, 12 Jul 2009 01:03:59 -0700

> place an semantic significance on the split between a/b and c/d?

I don't believe that header value is conforming, according to the
draft.  I can define the processing behavior, if you like.  I'd
probably define it to ignore everything after the comma (likewise,
ignore any Sec-From header after the first).

Adam

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 12 Jul 2009 18:48:57 +1000

If that's the case, you can just as easily define it as

Sec-From: "a.com", "b.com"

It's a minor point, but as an HTTP implementer, it's annoying to have  
yet another Header syntax floating around...

Cheers,

---

From: Adam Barth <[email-masked]>
Date: Sun, 12 Jul 2009 10:43:21 -0700

On Sun, Jul 12, 2009 at 1:48 AM, Mark Nottingham<[email-masked]> wrote:
> It's a minor point, but as an HTTP implementer, it's annoying to have yet
> another Header syntax floating around...

I'm confused.  Where did the quotes come from?  Also, my understanding
(which might well be wrong) is that defining the format using commas
requires servers to handle both the forms

Sec-From: http://a.com, http://b.com

and

Sec-From: http://a.com
Sec-From: http://b.com

because those two are equivalent.  The ordering of items in the header
is significant, so the above is not semantically equivalent to

Sec-From: http://b.com
Sec-From: http://a.com

Do other HTTP headers rely on ordering information between headers?
Put another way, are we guaranteed (and does it occur in practice)
that proxies won't re-order the headers?

The above considerations lead me to believe that using commas is just
inviting bugs for little gain.

Adam

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 13 Jul 2009 09:45:43 +1000

On 13/07/2009, at 3:43 AM, Adam Barth <[email-masked]> wrote:

> I'm confused.  Where did the quotes come from?

It's necessary because a URL can contain a comma.

> Also, my understanding

Yes, within the same field-name; read rfc2616 section 4.2:

    The order in which header fields with the same field-name are  
received is therefore significant to the interpretation of the  
combined field value, and thus a proxy MUST NOT change the order of  
these field values when a message is forwarded.

> inviting bugs for little gain.

That perspective is understandable, if you're starting from a clean  
slate.  From where I sit, every time somebody adds a new type of  
syntax, new parsing code has to be written, increasing the chance of  
errors. It also means that people have to learn yet another  
specialized syntax rather than leveraging existing knowledge.

---

From: Adam Barth <[email-masked]>
Date: Sun, 12 Jul 2009 16:57:30 -0700

On Sun, Jul 12, 2009 at 4:45 PM, Mark Nottingham<[email-masked]> wrote:
> That perspective is understandable, if you're starting from a clean slate.
>  From where I sit, every time somebody adds a new type of syntax, new
> parsing code has to be written, increasing the chance of errors. It also
> means that people have to learn yet another specialized syntax rather than
> leveraging existing knowledge.

The quotes are kind of disaster, no?  What if we see single quotes?
What if the quotes aren't there?  These kinds of issues have plagued
the Content-Type header.

Adam

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 13 Jul 2009 10:25:35 +1000

Only because parameters are ill-defined (something we're fixing in  
HTTPbis).

Any format can have parsing errors; e.g., as soon as someone finds a  
way to get a space into the header you've defined, it's going to be an  
issue.

Cheers,

On 13/07/2009, at 9:57 AM, Adam Barth wrote:

>> slate.

---

From: Adam Barth <[email-masked]>
Date: Sun, 12 Jul 2009 19:33:13 -0700

On Sun, Jul 12, 2009 at 5:25 PM, Mark Nottingham<[email-masked]> wrote:
> Any format can have parsing errors; e.g., as soon as someone finds a way to
> get a space into the header you've defined, it's going to be an issue.

Can you elaborate on this?  How can you have a space in the middle of
a host name?

Adam

---

From: Julian Reschke <[email-masked]>
Date: Mon, 13 Jul 2009 08:33:46 +0200

> It's necessary because a URL can contain a comma. 

I think angle brackets as URL delimiters are used more frequently (Link 
header, WebDAV headers...).

BR, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 13 Jul 2009 16:40:28 +1000

That works too.

On 13/07/2009, at 4:33 PM, Julian Reschke wrote:

>> It's necessary because a URL can contain a comma. ...
>
> I think angle brackets as URL delimiters are used more frequently  
> (Link header, WebDAV headers...).
>
> BR, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 17 Jul 2009 09:58:18 +0200

> semantics because of header coalescing.

Proably. Any header which may be (is) repeated can be joined into a
single comma-separated list in the same order. But the reverse is not
true unless one knows the header is in fact a list header.

Any specification which allows for multiple instances of a header but
where a comma separated list of those same values is not the same
thing/meaning is not following HTTP guidelines on header format.

For single-valued headers there is almost no restrictions on formatting.

Regards
Henrik

---

From: "Anne van Kesteren" <[email-masked]>
Date: Wed, 22 Jul 2009 15:58:13 +0200

> It's necessary because a URL can contain a comma.

FYI: Sec-From does not take a URL.

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

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 23 Jul 2009 11:35:52 +1000

If the contents can't contain a comma by definition, and you're  
relatively sure that they'll be generated correctly, omitting quotes  
should be fine.

---

From: Adam Barth <[email-masked]>
Date: Wed, 22 Jul 2009 19:21:41 -0700

Anne,

I wonder if this syntax would work for CORS too?  We can take the
discussion to web-apps if you like, but the idea is if you get a
redirect (e.g., of a DELETE), then you can add a second Origin header
to the request instead of modifying the existing header.

Adam

On Wed, Jul 22, 2009 at 6:35 PM, Mark Nottingham<[email-masked]> wrote:
> If the contents can't contain a comma by definition, and you're relatively
> sure that they'll be generated correctly, omitting quotes should be fine.
>
>

---

From: Ian Hickson <[email-masked]>
Date: Thu, 23 Jul 2009 06:04:44 +0000 (UTC)

On Wed, 22 Jul 2009, Adam Barth wrote:
> redirect (e.g., of a DELETE), then you can add a second Origin header to 
> the request instead of modifying the existing header.

I think that relying on sites to handle multiple headers correctly 
(especially when in the common case there will only be one) is asking for 
trouble. I know that they'd be breaking the spec if they didn't, but that 
isn't going to be any consolation when they get tricked.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 23 Jul 2009 16:06:30 +1000

If they're using CGI or pretty much any Web framework, it'll be done  
for them automatically. This is actually very well-implemented.

---

From: Adam Barth <[email-masked]>
Date: Fri, 31 Jul 2009 12:43:29 -0700

Thanks for your comments Mark.  I've updated the draft, but I have not
yet addressed all of your comments.  I tried to handle the technical
comments in this round.  I'll hand the presentational comments in the
next round.  Detailed response below.

> Referer and Origin, perhaps in an Appendix.

I've pushed these comments to the next version.

> URI. This doesn't make sense; perhaps you mean IRI?

I will address these comments when I have some time to study all the
various URL/URI/IRI/DanCURL possibilities.

> * The /variable/ syntax is distracting.

There were some good alternatives suggested later in the thread.  I'll
probably move to hyphenated variable names in the next draft.

> would be better specified as:

I've pushed deciding whether to present the requirements as algorithms
or declaratively to the next draft.

> context of what these are, how they might be used, etc.

It's difficult to write down a correct spec here because these vary
from implementation to implementation.

> out (either here or in a conformance criteria section).

Oops.  Missed this one.  I'll get it next time.

> pull it in line with the definitions of other HTTP headers.

Done.  I didn't quote the origin values as you suggest in a later
message because I don't believe it's possible to have a comma or a
space in an origin serialization.

Adam

---

From: Adam Barth <[email-masked]>
Date: Fri, 31 Jul 2009 12:57:44 -0700

On Wed, Jul 22, 2009 at 11:06 PM, Mark Nottingham<[email-masked]> wrote:
> If they're using CGI or pretty much any Web framework, it'll be done for
> them automatically. This is actually very well-implemented.

I've relied upon Mark's email above and modified the spec to use
commas to delimit serialized origins.  However, I'm willing to reverse
this decision if new evidence comes to light regarding how well
supported this syntax actually is.

Adam