Spotted by @hawkowl.
RFC 7540 Section 8.1.2.5 reads as follows:
To allow for better compression efficiency, the Cookie header field MAY be split into separate header fields, each with one or more cookie-pairs. If there are multiple Cookie header fields after decompression, these MUST be concatenated into a single octet string using the two-octet delimiter of 0x3B, 0x20 (the ASCII string "; ") before being passed into a non-HTTP/2 context, such as an HTTP/1.1 connection, or a generic HTTP server application.
We are very much in violation of that MUST right now. This is breaking some Twisted applications that work with multiple cookies, whereby cookies are getting lost because Twisted (rightly) expects only a single cookie header.
For the moment, this issue tracks only the MUST. Later on we may want to tackle the other side of this (the MAY).
My belief is that the last sentence of that paragraph makes this a hyper-h2 issue, not a hpack issue: HTTP/2 contexts may want to see those headers individually, but in general we shouldn't show them to users that way. This means we need to add another step to the inbound header normalization pipeline that grabs all cookie fields and concatenates them together.
Spotted by @hawkowl.
RFC 7540 Section 8.1.2.5 reads as follows:
We are very much in violation of that MUST right now. This is breaking some Twisted applications that work with multiple cookies, whereby cookies are getting lost because Twisted (rightly) expects only a single cookie header.
For the moment, this issue tracks only the MUST. Later on we may want to tackle the other side of this (the MAY).
My belief is that the last sentence of that paragraph makes this a hyper-h2 issue, not a hpack issue: HTTP/2 contexts may want to see those headers individually, but in general we shouldn't show them to users that way. This means we need to add another step to the inbound header normalization pipeline that grabs all cookie fields and concatenates them together.