Re: Encouraging a healthy HTTP/2 ecosystem

On Tue, Jul 01, 2014 at 01:19:46PM -0700, Jeff Pinner wrote:
> > William, I tend to disagree with you on this argument. Just because RFC2616
> > did not impose limits on header size, it does not mean that implementations
> > would have to support unbounded lengths. If the sole purpose of CONTINUATION
> > is to support headers larger than 16383 bytes, then any product which is not
> > able to support more than this size of headers will have no use of CONTINUATION
> > and will not even be able to deal correctly with them, so it better not try to
> > implement them and do stupid things.
> 
> It's not quite the same because even if you want to reply to requests
> with more than 16k of headers with an HTTP 431 for example, you don't
> necessarily want to tear down the connection so you can reply to other
> outstanding requests or accept new ones.

I mean at least in 1.1, in practice you generally do so because if your state
machine has reached the end and is not able to parse the headers past the end
of the buffer, and you can't always recover. Still that situation is acceptable
since it should almost never happen, all you need is to report it and log it.

When you reject a client on such a condition, you generally don't expect that
client to strip off cookies, referer, user-agent or whatever, so definitely
deny it any further access, and your connection becomes really useless. This
is a serious protocol error which is hard to recover from, so if you break the
connection it's not a big deal.

> This means that you must process that CONTINUATION frames since they
> can update the HPACK header table. You can of course discard the
> headers fields.

As I said above, all that dangerously complicated stuff for a dead
connection anyway is not worth it. Better kill the connection and restart
with something sane if needed.

Willy

Received on Tuesday, 1 July 2014 20:32:00 UTC