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?