- From: Willy Tarreau <w@1wt.eu>
- Date: Tue, 1 Jul 2014 22:08:34 +0200
- To: "William Chan (?????????)" <willchan@chromium.org>
- Cc: Jason Greene <jason.greene@redhat.com>, HTTP Working Group <ietf-http-wg@w3.org>
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. Regards, Willy
Received on Tuesday, 1 July 2014 20:09:02 UTC