Re: H2 vs responses which should not carry any payload

Willy,

You describe having a semantic layer that can have H1 or H2 either side.
So let's consider the case of H1->Poxy->H2.  In this case if the server
gives you a body to a 204/304 response or a HEAD request, then you have no
way of passing them back to the client  - as it breaks H1.  You must filter
them in that case in your semantic layer, thus it would make sense to me to
also filter them in the H2->Proxy>H2 case.

cheers


On Fri, 23 Oct 2020 at 06:57, Willy Tarreau <w@1wt.eu> 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
>
>

-- 
Greg Wilkins <gregw@webtide.com> CTO http://webtide.com