Re: Our Schedule

On Wed, May 28, 2014 at 11:21 AM, David Krauss <potswa@gmail.com> wrote:

>
> 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.
>
>
​Yeah, you are right, GOAWAY can be avoidable in this case.​
​If the incoming header is very very long, GOAWAY may be an option.​



> Yes, there would be a RST_STREAM upstream and downstream, and that would
> suck. What would even be an appropriate error code? Internal error?
>
>
​ENHANCE_YOU_CALM is suggested in the another thread.

Best regards,
Tatsuhiro Tsujikawa​



>
> 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.
>
>