RE: Encouraging a healthy HTTP/2 ecosystem

Presumably nothing -- the 502 carries END_STREAM, so the server is (at least) half-closed from the server side.  The connection is still valid, because HPACK processed all the input, it just stopped emitting anything.

-----Original Message-----
From: Willy Tarreau [mailto:w@1wt.eu] 
Sent: Tuesday, July 1, 2014 2:10 PM
To: Jeff Pinner
Cc: Johnny Graettinger; William Chan (?????????); Jason Greene; HTTP Working Group
Subject: Re: Encouraging a healthy HTTP/2 ecosystem

On Tue, Jul 01, 2014 at 02:04:16PM -0700, Jeff Pinner wrote:
> > In 1.1 it would return 502 bad gateway. In 2.0, assuming I manage to 
> > implement it to the server, I don't expect it to be able to 
> > multiplex multiple streams over a single connection before we've 
> > finished HTTP/3. I'm serious. 2.0 is a major architecture change for 
> > low-level intermediaries. So I'd say that for now, with the elements 
> > I have, a protocol error on 2.0 will be handled the same way as in 
> > 1.1 : the connection will be torn down and the effects will be exactly the same : only the request using that connection will be impacted.
> 
> What we do:
> 
> 1) HPACK is configured to stream headers and discard all headers above 
> a certain side (see github.com/twitter/hpack decider maxHeaderSize).
> 2) The reverse proxy aggregates the response headers and if it they 
> have been truncated (because they were above the max size) it responds 
> with a 502.

But what do you do then with the server connection and/or stream when you send the 502 to the client ?

Willy

Received on Wednesday, 2 July 2014 16:24:08 UTC