Re: Limiting header block size

On 22.05.2014 14:53, Martin Thomson 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.
+1
> 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.
The sender then shouldn't send the request and notify the user / return 
an error message. If the receiver is resetting the stream the result 
will be not much different.
>
> (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.
Another possibility would be to conclude the protocol is broken and 
should be changed :)

Roland

Received on Thursday, 22 May 2014 13:25:35 UTC