HTTP header representation in Fetch

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?

I would very much appreciate feedback from all of you on this matter
so we can settle this for good. I copied www-archive to make this
publicly available. I encourage you all to do the same.


-- 
https://annevankesteren.nl/

Received on Tuesday, 19 January 2016 09:27:41 UTC