- From: Willy Tarreau <w@1wt.eu>
- Date: Fri, 27 Jun 2014 22:16:00 +0200
- To: Patrick McManus <pmcmanus@mozilla.com>
- Cc: Johnny Graettinger <jgraettinger@chromium.org>, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>, Mark Nottingham <mnot@mnot.net>, Simone Bordet <simone.bordet@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Hi Pat,
On Fri, Jun 27, 2014 at 11:12:04AM -0400, Patrick McManus wrote:
> today's firefox nightly has h2-13 support btw. continuation support has
> been around as long as its been in the spec, but we don't send them unless
> there is just no room left in the headers.
>
> I think pretty much nobody likes continuations, but we accept them as a
> necessary long tail compatibility mechanism. It seems totally appropriate
> for uninterested servers to 413 requests that use them - we certainly won't
> generate a continuation unless we don't have another option. As with all
> arbitrary limits (url length, etc..) allowing higher thresholds will buy
> you interop at the tail - but you may not care about the tail.
Then probably your and Johnny's choices indicate that there are at least
two reasonable implementations on the client side. Maybe we could make
the spec a bit stricter an only allow CONTINUATION frame if a header is
over 16kB and indicate that it is legal for the recipient to reject them
in any other case ? That would solve both sides of the problem :
- recipients not interested in supporting more than 16kB do not need
to implement them - at all -
- there is no incentive for senders to produce them unless absolutely
necessary, which ensures that recipients who do not implement them
will never get into trouble below 16kB
Then we're exactly in the same situation we used to face with H/1 which
is that some implementations which do not support large enough headers
will simply reject the message, and nothing changes for anyone.
Would that be OK for every one ?
Willy
Received on Friday, 27 June 2014 20:16:31 UTC