W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Our Schedule

From: David Krauss <potswa@gmail.com>
Date: Tue, 27 May 2014 08:27:44 +0800
Cc: Greg Wilkins <gregw@intalio.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <27539AC2-83EC-4AE3-AAC1-19247F499BE1@gmail.com>
To: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>

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?

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.

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?


Received on Tuesday, 27 May 2014 00:28:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC