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

Re: HTTP header representation in Fetch

From: Ryan Sleevi <sleevi@google.com>
Date: Tue, 19 Jan 2016 11:47:53 -0800
Message-ID: <CACvaWvbS1Ke7CSMNp5d+ypkhtk67zjUhSC9ekJsfukqdRoF+1g@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Patrick McManus <pmcmanus@mozilla.com>, Honza Bambas <hbambas@mozilla.com>, Mark Nottingham <mnot@mnot.net>, Youenn Fablet <youennf@gmail.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>
On Tue, Jan 19, 2016 at 1:27 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> The folks at WebKit have brought up a concern with representing HTTP
> headers in a data structure that represents how they went over the
> wire. In particular, Fetch ("the browser's implementation of HTTP" and
> some) can distinguish between
>
>   X: 1
>   A: 2
>   X: 3, 4
>
> and
>
>   X: 1, 3, 4
>   A: 2
>
> whereas WebKit's and Apple's network library cannot.
>
> I thought this was important for cookies (that they could not be
> combined), but there's nothing in RFC 7230 that supports that.
>
> I also found that browsers will either pick the first or the last
> header (when in theory there cannot be duplicates) in a list, without
> accounting for commas in the value. E.g., I'm pretty sure I've seen
>
>   Location: x,y
>   ...
>   Location: z
>
> redirect to relative/to/x,y which would not be possible to specify if
> we combine all headers as WebKit appears to do.
>
> I have to say I'm very sympathetic to WebKit's views here as their
> representation completely matches the spirit of the HTTP specification
> and would be ideal as it means developers do not get to rely on
> idiosyncrasies of particular implementations of HTTP. However, is
> going down that route web-compatible or is WebKit unknowingly running
> into certain issues other browsers avoid?
>

Hi Anne,

I must admit, I'm not entirely clear as to what you're asking.

In the case of headers that follow the #rule construct, any number of
intermediaries (or, for that matter, processing libraries, such as CGI
interfaces) are perfectly permitted to arrange the headers such that "X: 1,
3, 4" is valid, iff X follows #rule syntax (c.f Section 4.3 of RFC 2616).
So any application that relies on how it was sent / received over the wire
is, in my mind, improperly coded, and not something that needs to be
supported.

The Location header doesn't follow the #rule syntax, ergo combining to
"Location: x,y,z" is invalid, which I understood your remarks to be
suggesting it should be?
Received on Tuesday, 19 January 2016 19:49:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 19 January 2016 19:49:44 UTC