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

Re: HTTP header representation in Fetch

From: Honza Bambas <hbambas@mozilla.com>
Date: Tue, 19 Jan 2016 21:16:55 +0100
To: Ryan Sleevi <sleevi@google.com>, Anne van Kesteren <annevk@annevk.nl>
Cc: Patrick McManus <pmcmanus@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>
Message-ID: <898e132a-bddf-b960-2689-46058c44cbc9@mozilla.com>
On 1/19/2016 20:47, Ryan Sleevi wrote:
> 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?

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.


Received on Wednesday, 20 January 2016 09:53:38 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 20 January 2016 09:53:39 UTC