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

Re: HTTP header representation in Fetch

From: Anne van Kesteren <annevk@annevk.nl>
Date: Wed, 20 Jan 2016 09:41:17 +0100
Message-ID: <CADnb78iwOoQ=3frq0TCgc16nXQ5QQoQOJ_UAAcyC4g2j1UXY_g@mail.gmail.com>
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

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.

Received on Wednesday, 20 January 2016 08:41:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 20 January 2016 08:41:44 UTC