W3C home > Mailing lists > Public > www-archive@w3.org > January 2016

Re: HTTP header representation in Fetch

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 20 Jan 2016 15:51:02 +1100
Cc: youenn fablet <youennf@gmail.com>, Anne van Kesteren <annevk@annevk.nl>, Patrick McManus <pmcmanus@mozilla.com>, Honza Bambas <hbambas@mozilla.com>, Takeshi Yoshino <tyoshino@google.com>, Jacob Rossi <Jacob.Rossi@microsoft.com>, Alex Christensen <achristensen@webkit.org>, Edward O'Connor <hober@apple.com>, Ben Kelly <bkelly@mozilla.com>, Nikki Bee <nikkicubed@gmail.com>, www-archive <www-archive@w3.org>
Message-Id: <B3DBE360-6353-44EE-A1B2-7D0499A399CB@mnot.net>
To: Ryan Sleevi <sleevi@google.com>

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

This archive was generated by hypermail 2.3.1 : Wednesday, 20 January 2016 04:51:39 UTC