Re: HTTP header representation in Fetch

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.


-hb-

[1] 
http://hg.mozilla.org/mozilla-central/annotate/b67316254602/netwerk/protocol/http/nsHttpHeaderArray.h#l156

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