Re: Limiting header block size

Martin,

I agree that realistically we cannot limit the size of header blocks.

However, is there any reason to continue the restriction that header blocks must be contiguous? Allowing intervening DATA frames on other streams would go a long way to minimizing the impact of large header blocks on streaming content and prioritization in general.  I fear that if that issue is not addressed we'll end up with low adoption of HTTP/2 or implementations that open a separate connection for high-priority traffic rather than using the priority scheme in HTTP/2.


On May 22, 2014, at 8:53 AM, Martin Thomson <martin.thomson@gmail.com> wrote:

> The discussion on header blocks and flow control raised the question
> of whether it is appropriate to allow an endpoint to limit the size of
> header block it accepts.
> 
> Due to the design of HPACK, there are many cases where a server or
> intermediary is forced to buffer an entire header block.  This is
> because critical routing information like :path, :authority and
> :scheme can be placed anywhere in a header block.  More importantly,
> some of these are highly likely to be in the reference set, causing
> them to be emitted only at the end of the block.
> 
> This means that processing a header block can require an essentially
> unbounded amount of state for many implementations.  Being able to
> limit this commitment would be good.
> 
> However, it's not clear what an announced limit would enable at a
> sender.  Conforming to a limit ultimately requires a sender to drop
> header fields.  It seems unlikely that a sender would be able to
> arbitrarily drop header fields in order to comply with an arbitrary
> limit.  Header fields are there to express semantics, and it's
> difficult to know what fields are safe to drop without knowing
> application requirements in some detail.
> 
> (Someone suggested that a block could be split, but that doesn't work
> due to the structure of the protocol.)
> 
> Thus, I conclude that changing the protocol is not advisable.
> Implementations that receive more header information than they are
> willing to tolerate can process any updates to the header table and
> then reset the corresponding stream (which for a PUSH_PROMISE would be
> the promised stream, of course).
> 
> I will raise an editorial issue to note the DoS implications of
> excessively large header blocks and the above method for handling
> them.
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair