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