RE: H2 vs responses which should not carry any payload

Yes, client-role, not client machines.  Thanks for the details, Eric!

-----Original Message-----
From: Eric Lawrence <Eric.Lawrence@microsoft.com> 
Sent: Friday, October 23, 2020 10:57 AM
To: Bence Béky <bnc@chromium.org>; Willy Tarreau <w@1wt.eu>
Cc: HTTP Working Group <ietf-http-wg@w3.org>; Mike Bishop <mbishop@evequefou.be>
Subject: RE: H2 vs responses which should not carry any payload

The term "client-only stack" is potentially ambiguous. WinHTTP can and is sometimes used as a HTTP client running on servers.

In the case in question (broken Microsoft's web properties in spring), the problem was is that the http.sys HTTP Server code on our "Azure front door" servers would accept the client's H2 request, see the header block did not set the END_STREAM flag indicating that there was no body, and convert that request to a GET with a Transfer-Encoding: chunked. That request was then handed off to WinHTTP for forwarding to the backend servers, but WinHTTP would reject the request because it does not permit Transfer-Encoding to appear on GET or HEAD requests. 

The June "fix" was to have our "front door" servers simply skip adding the TE:Chunked to inbound GETs even if the H2 headers did not indicate there would be no body, allowing WinHTTP to forward the request without breaking.

WinHTTP continues to disallow TE:Chunked on GET/HEAD, and we believe that an issue very similar to the one described previously will also occur for servers running the IIS ARR load balancer software.

-Eric

-----Original Message-----
From: Bence Béky <bnc@chromium.org>
Sent: Friday, October 23, 2020 9:42 AM
To: Willy Tarreau <w@1wt.eu>
Cc: HTTP Working Group <ietf-http-wg@w3.org>; Mike Bishop <mbishop@evequefou.be>; Eric Lawrence <Eric.Lawrence@microsoft.com>
Subject: Re: H2 vs responses which should not carry any payload

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 <bnc@chromium.org> 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.)
>
> Bence