Re: Our Schedule

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)

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 get the sense that HTTP/2 reverse proxies can’t use multiplexing
> upstream. Is anyone yet testing reverse proxies?
>
> Receiving CONTINUATION forever is unrealistic situation.
>
>
> Receiving CONTINUATION even once is unusual, if not unrealistic. The frame
> size was reduced simply to generate more CONTINUATIONs, so just as easily
> they could be all but eliminated. Yet header-streaming protocols come up as
> a necessary future use case. If they are not nice to have and we don’t want
> to support them, then a line should be drawn and a limit set.
>
> Are there any uses **in practice on the public internet** for headers
> longer than 64K as serialized by HTTP/1.1?
>
>
​I don't have actual statistics of length of the header.  But server
software have its own limit of header buffers.
For example, HAproxy uses 8K buffer for entire request headers by default
and its manual says it is not recommended to change the value, so limit is
somewhere near it?

Best regards,
Tatsuhiro Tsujikawa

Received on Tuesday, 27 May 2014 14:50:39 UTC