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?