One question that is asked here is whether it is fine to remove the support
of multiple not-combinable headers from the fetch Headers API, both read
and write side.
That would mean that a web app could add multiple headers with the same
name only if it is fine if they can be combined by the browser. Whether or
not putting requirements on how browsers should serialize these headers is
out of scope here.
Another sub-point is that, as it currently stands, the fetch Headers API
could potentially make the buggy "Location" header behavior more common.
Headers::get is indeed returning the value of the first header with a given
name.
>From what Mozilla is doing and also how WebKit is processing headers
internally, having a get-as-combined returning a string and a
get-as-uncombined returning a vector of strings might be handy.
y
Le mar. 19 janv. 2016 à 20:48, Ryan Sleevi <sleevi@google.com> a écrit :
> 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?
>