Re: Limiting header block size

We already have a HTTP status code for this: <http://tools.ietf.org/html/rfc6585#section-5>

Why push it down into the framing layer?
 
There’s a LOT more chance for conveying the semantics of what went wrong in a full HTTP response; you can do it in the headers, status codes, etc. In contrast, an error code is exactly one bit, and a recipient is inevitably going to be left scratching their head and asking “HOW should I enhance my calm?”

Not to mention, doing it this way will require APIs to figure out how to surface that information, and HTTP1->2 gateways trying to figure out out to represent ENHANCE_YOUR_CALM to their clients (in this case, they’d likely use the wrong status code!).

Let’s not duplicate HTTP semantics down into the framing layer, please. I know that if we were doing this from scratch, we’d have a better separation between resource/representation semantics and protocol behaviours like this — but we’re not doing it from scratch.

Cheers,


On 22 May 2014, at 11:51 pm, Martin Thomson <martin.thomson@gmail.com> wrote:

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

--
Mark Nottingham   http://www.mnot.net/

Received on Friday, 23 May 2014 01:21:36 UTC