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

On 13/07/2009, at 3:43 AM, Adam Barth <w3c@adambarth.com> wrote:

> On Sun, Jul 12, 2009 at 1:48 AM, Mark Nottingham<mnot@mnot.net> wrote:
>> 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...
>
> I'm confused.  Where did the quotes come from?

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

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

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.

>
> The above considerations lead me to believe that using commas is just
> 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.