W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2009

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

From: Mark Nottingham <mnot@mnot.net>
Date: Sun, 12 Jul 2009 18:48:57 +1000
Cc: Ian Hickson <ian@hixie.ch>, collinj@cs.stanford.edu, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <CF12955F-05D0-42E5-B88D-29D95D6896B7@mnot.net>
To: Adam Barth <w3c@adambarth.com>
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...


On 12/07/2009, at 6:03 PM, Adam Barth wrote:

> On Sat, Jul 11, 2009 at 6:01 PM, Mark Nottingham<mnot@mnot.net> wrote:
>> On 09/07/2009, at 3:58 PM, Adam Barth wrote:
>>>> * 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.
>> 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?
> 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

Mark Nottingham     http://www.mnot.net/
Received on Sunday, 12 July 2009 08:50:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:50 UTC