- From: Jason Greene <jason.greene@redhat.com>
- Date: Fri, 27 Jun 2014 15:35:29 -0500
- To: Willy Tarreau <w@1wt.eu>
- Cc: Patrick McManus <pmcmanus@mozilla.com>, 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>
On Jun 27, 2014, at 3:16 PM, Willy Tarreau <w@1wt.eu> wrote: > 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 ? IMO it doesn’t help that much. If recipients are not going to implement them then it should be an optional extensional vs an interop mess. Although, I honestly don’t understand why multiplexing has to be fundamentally broken to support large headers. Minimal changes can be done to resolve this problem. Sure it’s late in the process but better late than the pain of a problematic spec. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat
Received on Friday, 27 June 2014 20:36:24 UTC