On 1/19/2016 20:47, Ryan Sleevi wrote:
On Tue, Jan 19, 2016 at 1:27 AM, Anne van Kesteren <ann...@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?
Merging of certain headers is in Gecko prohibited for security reasons
(injection attacks). We explicitly hard-fail the response when there is
more than one instance of Content-Length, Content-Disposition or
Location. Hence merging e.g. Location is a very bad idea.
Then we have an even wider list of headers that must not be present in a
response more than once, see [1]. We only accept value of the first
presence of such a header, others are silently ignored. Only on those 3
mentioned above we fail with an error when duplicated.
Headers NOT on the list at [1] are merged to one only, so that upper
layers see them as Header: value1, value2, ... We definitely do this
also for the Set-Cookie header.
-hb-
[1]
http://hg.mozilla.org/mozilla-central/annotate/b67316254602/netwerk/protocol/http/nsHttpHeaderArray.h#l156
