Re: H2 vs responses which should not carry any payload

[Bence Béky <[e-mail]>]

Hi Willy,

Sorry, my previous e-mail was incorrect.  Chrome did run into some
issues with buggy servers, and a fix to those servers has been
deployed since.  Separately, the same bug is thought to exist in
WinHTTP.  However, WinHTTP is a client-only stack, so this should only
affect responses, not requests.  Which is exactly what you are worried
about.

Thanks to Mike Bishop for correcting me in private.

Also cc'ing Eric Lawrence who might have more details to share.

Bence

On Fri, Oct 23, 2020 at 7:45 AM Bence Béky <[e-mail]> wrote:
>
> Hi Willy,
>
> On Fri, Oct 23, 2020 at 12:57 AM Willy Tarreau <[e-mail]> wrote:
> >
> >
> > 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).
> >
> >
>
> At some point during the GREASE experiments Chrome removed the
> END_STREAM flag from every HEADERS frame, then sent a frame of
> reserved type, then an empty DATA frame with END_STREAM, and I found
> that not every server accepts this.  To my best knowledge WinHTTP
> still fails to process such a request (ever without the reserved
> frame) if the request method is GET.  My interpretation of RFC7540 is
> that such a request is spec compliant, but in practice Chrome cannot
> send them at this point.  (The GREASE experiment continues only on
> requests with a request body.)
>
> Bence