Re: Our Schedule

On 2014–05–27, at 10:49 PM, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> wrote:

> 
> 
> 
> On Tue, May 27, 2014 at 9:27 AM, David Krauss <potswa@gmail.com> wrote:
> 
> On 2014–05–26, at 10:07 PM, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> wrote:
> 
>> ​Server and intermediaries can respond 431 if incoming headers are too large and refuse to forward to the shared backend connection.
> 
> What is the correct behavior of a proxy that gets excessive headers from a server?
> 
> 
> ​There are several actions proxy can take:
> 1) Ignore excessive headers
> 2) RST_STREAM
> 3) GOAWAY (if one header is too large to handle and keep in header table)

Off topic a bit, but if one header is too large to fit in the header table, the current spec of HPACK requires the table to be cleared. I think the table should be left unchanged; is this an erratum?

Anyway, no need to GOAWAY in that case.

Yes, there would be a RST_STREAM upstream and downstream, and that would suck. What would even be an appropriate error code? Internal error?

> 
> In framing protocol wise, all are correct behavior.​  Proxy has right to protect its own.
>  
> What if the header stream takes too long, without being particularly large? Then the problem is not too many headers at all. Indeed, for a reverse proxy with a slow client, this is sure to happen as sure as streaming kicks in at all.
> 
> 
> ​This is not limited to HEADERS.  Just send 1 byte of first header of any frame and pause.​
> ​This is good candidate for the timeout, isn't it?​

I’m talking about the connection between the reverse proxy and the server. There should be only one connection there, representing all the clients assigned to the server. The reverse proxy is trusted, and it can always send complete data frames. However it is still at the mercy of the client as for complete header blocks, under a streaming policy.