Re: #551: Limiting header sizes

Hi Greg,

On Wed, Jul 16, 2014 at 02:01:16PM +1000, Greg Wilkins wrote:
> Mark,
> 
> I think that a declared header limit, regardless of exact semantics, should
> be declared in terms of uncompressed header size rather than header block
> size.
> 
> We should be decoupling HTTP semantics from the framing layer and with all
> the other proposals being currently considered (large frames, fragmented
> headers, etc.) then I think we are hopefully moving away from having any
> header limits (implicit or explicit) related to the frame size.
> 
> With regards to the change in semantics that you suggest, I'm fine with
> that.   It really just means that it is not a protocol error for a sender
> to ignore the setting.

I understand the point you're making and I too think that uncompressed
header limit could be useful, but I think that it will be very implementation
dependant. For instance h2->h1 gateways will have a hard limit which basically
is the h1-encoding of all the headers (including possible repetition of certain
very large multiple headers). So there's no 100%-certain uncompressed size in
this case.

And that's where I think that Mark's proposal could solve this issue
elegantly, just the in the same way we do it in h1 right now : if you
send something reasonably small, you don't need to care. If you're sending
large things, close to suggested common limits, get prepared to receive a
bunch of 431. I like it because it avoids precise accounting and allows
recipients to detect not in the framing but in the semantics and/or
processing that contents finally don't fit in the buffer anymore.

For example, right now haproxy receives h1-encoded headers and keeps a
reserve for header rewrites and additions. If you want to add far too large
headers to a large request and the result doesn't fit in the buffer anymore,
you get an error. This case very rarely happens (you have to write a special
config for this) but it's easy to handle and I don't have to advertise a
certain size that would be hard to account for on the sender's side.

Cheers,
Willy

Received on Wednesday, 16 July 2014 05:13:55 UTC