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

Re: Limiting header block size

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 23 May 2014 11:21:06 +1000
Cc: Roland Zink <roland@zinks.de>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <FA3A6096-ABF8-4111-AA12-D0254158CA4C@mnot.net>
To: Martin Thomson <martin.thomson@gmail.com>
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.


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

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