Re: HTTP header representation in Fetch

On 20 Jan 2016, at 8:36 am, Ryan Sleevi <sleevi@google.com> wrote:
> 
> Yes, sorry if that wasn't clearer in how I phrased the question. I can't think of any API reason to support multiple non-combinable headers (e.g. multiple headers that don't support the #rule format), with the only exception being the Set-Cookie bit.

... and Cookie. I forget - is common practice there still to use multiple Cookie header fields, or are browsers actually taking advantage of the semicolon to delimit them?

Regardless, HPACK's design encourages Cookie to be sent in separate header fields, to get better compression.


>> That would mean that a web app could add multiple headers with the same name only if it is fine if they can be combined by the browser. Whether or not putting requirements on how browsers should serialize these headers is out of scope here.
> 
> Is the assumption that all new headers adhere to the #rule syntax, unless otherwise blacklisted? That's certainly the approach Chrome has taken - see https://code.google.com/p/chromium/codesearch#chromium/src/net/http/http_util.cc&l=393

For the purpose of recipients combining them into comma-separated strings, yes; see <http://httpwg.github.io/specs/rfc7230.html#rfc.section.3.2.2>. However, you can't split a header value on commas until you know its syntax.


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

Received on Wednesday, 20 January 2016 04:51:39 UTC