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

Re: Limiting header block size

From: Roland Zink <roland@zinks.de>
Date: Thu, 22 May 2014 15:25:13 +0200
Message-ID: <537DFAB9.5090808@zinks.de>
To: ietf-http-wg@w3.org
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.
> 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 :)

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

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