Re: Encouraging a healthy HTTP/2 ecosystem

On Tue, Jul 01, 2014 at 01:00:17PM -0700, William Chan (?????????) wrote:
> Let's be clear here - we don't want to have a spec that doesn't mirror
> reality. If the spec says that something is a core feature, then it's
> terrible for it to fail to interop depending on which implementation you
> are speaking to.
> I think it's a completely fair argument to discuss whether or not
> CONTINUATION frames should be a core feature in the spec, or punted off to
> be negotiated instead or something. But *if* we keep it as a core part of
> the spec, it really must work, and I think it'd be healthy for the
> ecosystem if major implementations moved first to exercise as much of the
> spec as possible in order to prevent these kinds of interop issues from
> appearing.

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.

For example, haproxy is built by default with 16kB buffers, 15 of which can
receive headers. I'm not seeing any use in implementing continuations and
risk to break everything because of their significant extra complexity. Still
it's not the lack of continuations which causes the interop issue, but simply
the lack of support for more than 16kB headers. Every implementation has some
limits at some points.


Received on Tuesday, 1 July 2014 20:09:02 UTC