W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2020

Re: H2 vs responses which should not carry any payload

From: Willy Tarreau <w@1wt.eu>
Date: Fri, 23 Oct 2020 13:55:39 +0200
To: Bence Bky <bnc@chromium.org>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20201023115539.GA5205@1wt.eu>
Hi Bence,

On Fri, Oct 23, 2020 at 07:45:03AM -0400, Bence Bky wrote:
> Hi Willy,
> 
> On Fri, Oct 23, 2020 at 12:57 AM Willy Tarreau <w@1wt.eu> 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.)

Pretty useful indeed, thank you. I'm more concerned about the response
message however, since it's where we may have to perform some
adjustments to trim excess data. So this tends to confirm that we'll
have to deal with this at the H2 layer on the output path, to detect
that we're processing a HEADERS frame for a payload-less message, that
we need to set ES and that we ought to drop whatever else follows.

Cheers,
Willy
Received on Friday, 23 October 2020 11:55:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 23 October 2020 11:55:57 UTC