- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Wed, 20 Jan 2016 09:41:17 +0100
- To: Ryan Sleevi <sleevi@google.com>
- Cc: youenn fablet <youennf@gmail.com>, Patrick McManus <pmcmanus@mozilla.com>, Honza Bambas <hbambas@mozilla.com>, Mark Nottingham <mnot@mnot.net>, 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>
On Tue, Jan 19, 2016 at 10:36 PM, Ryan Sleevi <sleevi@google.com> wrote: > On Tue, Jan 19, 2016 at 12:37 PM, youenn fablet <youennf@gmail.com> wrote: >> One question that is asked here is whether it is fine to remove the >> support of multiple not-combinable headers from the fetch Headers API, both >> read and write side. > > 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. Since we don't expose cookies in the API at the moment, perhaps we can indeed settle for always combine. Not entirely clear yet what that means for the data structure the specification requires, since that does deal with cookies, but the sooner we change the API the better probably. I guess this means that we'd remove the getAll() method, make get() return all values as a single string, append() combines, and we'd have to figure out some iteration order that leaves implementations to do whatever they want. Lexicographical order? >> 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 I guess it's not much of a problem if folks can set these headers in combining ways on synthetic responses, since the network layer won't be affected by it anyway. -- https://annevankesteren.nl/
Received on Wednesday, 20 January 2016 08:41:44 UTC