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

Re: HEADERS and flow control

From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Date: Thu, 22 May 2014 14:47:04 +0300
To: Martin Thomson <martin.thomson@gmail.com>
Cc: David Krauss <potswa@gmail.com>, Mark Nottingham <mnot@mnot.net>, Roberto Peon <grmocg@gmail.com>, Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>, Michael Sweet <msweet@apple.com>
Message-ID: <20140522114704.GA4876@LK-Perkele-VII>
On Thu, May 22, 2014 at 03:49:01AM -0700, Martin Thomson wrote:
> We have asked before about setting a hard limit. That doesn't work. There
> are too many existing uses and users that wouldn't be able to use HTTP/2 as
> a result.
> A declared maximum (i.e., settings) might work.

Unfortunately, there are rather many possible limits, e.g.:
- Maximum total uncompressed size
- Maximum compressed size of individual header backed by stream
- Maximum uncompressed size of individual header backed by stream
- Maximum size of individual header backed by header table
- <probably fair amount of limits I can't quickly come up with>

Some of those may also be effectively infinity.

> You can't however reject a header block that you don't want. Not without
> also dumping the connection. Common state being what it is.

AFAIK, It is possible to do just corrupting the stream state, not connection
state (just mark things as failed and stop really emitting headers). Then upon
end of block, if things failed, try to deal with the corrupt stream.

The amount of temporary state required for such processing is just a few
bytes (the rest of working set comes from global state, which must be committed

> The best approach is to stream headers. The HPACK design permits it, and
> that allows for a bounded state commitment. The only real cost is the head
> of line blocking.

AFAIK, individual header sizes can still cause problems, since headers can be
very large and span multiple header frames.

Also, stuff like this can cause trouble:

... <lots of stuff> ...

These kind of cases are very nasty to handle in streaming manner, because the
webserver can't dispatch execution before almost the end of block.

Received on Thursday, 22 May 2014 11:47:30 UTC

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