Re: Limiting header block size

https://github.com/http2/http2-spec/issues/481

On May 22, 2014, at 9:08 AM, Michael Sweet <msweet@apple.com> wrote:

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

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair