- From: Willy Tarreau <w@1wt.eu>
- Date: Fri, 23 Oct 2020 06:54:26 +0200
- To: HTTP Working Group <ietf-http-wg@w3.org>
Hi all, we've recently faced a stupid case in haproxy with H2 and I realized that I didn't find the good response in the spec. What we've seen is that a client sends a HEAD request, which we forward to the server. In response the server returns an error with some payload (possibly a typical pre-made error page that doesn't care about the method), and haproxy forwards both the HEADERS and DATA frames to the client, then the client complains about protocol violations (I don't know yet what the client is for now but I don't think it's important). We were wondering where we ought to trim the payload in this case (and for 204/304 as well), whether we ought to do this while reading the response from the server or when sending the response do the client, and I figured that nowhere at all in 7540 is mentioned anything about 204/304/HEAD and that made me start to wonder if adjusting this at the H2 level is the right solution, and if we ought to do anything about it or not (since after all maybe everyone is right in this whole chain). We all know that 204/304/HEAD are between transport and semantics because for H1 these directly affect the parsing. From this perspective it would make sense to consider that H2 should drop these. But if we consider semantics only, it also makes sense to consider that H2 should let everything pass through. And even then, do all implementations accept, say, a HEADERS frame with no ES flag in response to a HEAD request, followed by an empty DATA frame carrying the ES flag ? At the semantic level it's OK since there's no payload, but I can understand how some could find it annoying to wait for DATA frames when no payload is expected (it's our case as well as part of the possible fixes for this). For those who want a bit more details, internally we're not directly forwarding frames but transcoding these into a version-agnostic HTTP representation that allows us to have either H1 or H2 on any side. This internal version carries the semantics. If we decide that H2 has nothing to do with this, we can decide to perform the filtering at the semantics layer, while knowing that when it comes to H1 it still has to take these special cases for the messaging anyway. It even makes me suspect that the contraints are double, in that HEAD/204/304 ought to see no response payload at the semantic layer, and that H1 is a special case in that it cannot accept that either at the transport layer to respect the messaging and that it's not a problem if it duplicates that check. I'm interested in any opinion on this subject (or any pointers to anything I could have missed). Thanks! Willy
Received on Friday, 23 October 2020 04:54:42 UTC