Re: Limiting header block size

On 22 May 2014 06:25, Roland Zink <roland@zinks.de> wrote:
> 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.

This has the advantage of bringing the error forward.

It has the disadvantage of being less flexible and introduces the need
to specify exactly how to measure the limit.

I'd say that in the common case, state commitment would have to be
based on post-decompression header fields.  But any setting we define
would need to be more deterministic and enforceable, so it would be
easiest to express a limit based solely on the size of header block
frames.

That creates a mismatch that could be exploited.  The problem then for
implementations is to choose what value to advertise.  In order to be
perfectly safe from attack, the limit would have to be so small it
would basically prevent any real messages from getting through.  Thus,
implementations are basically required to implement header block
discarding anyway.

The only advantage of a setting then is to - in some cases - cause
early detection of some errors, at the cost of more protocol
machinery.

So, I'm going to stick with my conclusion, and propose:
https://github.com/http2/http2-spec/pull/482

Received on Thursday, 22 May 2014 13:51:28 UTC