Re: H2 vs responses which should not carry any payload

[Mark Nottingham <[e-mail]>]

My .02 -

204/304/1xx and head responses are defined by HTTP's core semantics to not have a body. 

HTTP/1 enforced those in the framing mechanism (if you didn't, you lost framing reliability and Bad Things happened).

HTTP/2 doesn't explicitly enforce them, which means that we're now in similar territory to "Can GET have a request body?" ... and we've all seen how much angst that causes.

Whether or not you should strip them, generate an error, or just pass them through depends on what you're doing. In general, HTTP wants implementations that don't have to "know" the whole protocol, to allow extensions to be deployed successfully, and to allow simpler implementations to succeed. So while HTTP/1 requires that implementations understand these situations to maintain framing, I think it's reasonable to not have that requirement (and we don't) in HTTP/2, because framing doesn't depend upon it.

That doesn't mean that putting a response body on a 304 or HEAD response is interoperable or a good thing to do; it just means that you're not obligated to refuse that message -- and we should be super crisp in http-core about what this means.

Cheers,



> On 23 Oct 2020, at 3:54 pm, Willy Tarreau <[e-mail]> wrote:
> 
> 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
> 

--
Mark Nottingham   https://www.mnot.net/