Re: HEADERS and flow control

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

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

foo=bar
qux=zot
... <lots of stuff> ...
:path=/something
:method=GET
:authority=example.org

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.



-Ilari

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