- From: Jason Greene <jason.greene@redhat.com>
- Date: Fri, 27 Jun 2014 15:54:35 -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:46 PM, Willy Tarreau <w@1wt.eu> wrote: > On Fri, Jun 27, 2014 at 03:35:29PM -0500, Jason Greene wrote: >>> 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. > > It already works like this in H/1 and that's not an issue at all. Basically > you find small headers over the net and large ones inside certain corporate > environments. Depending on where you deploy, you'll know that some components > are suited or not. It already works like this today and products adapt to > their target. Sure but H/1 doesn’t implement multiplexing and state sharing. As you know, In H1 with a proxy you typically have a 1:1 client connection to the origin endpoint, so if one of the requests sense too big of a request it doesn’t really affect much. In H/2 if you coalesce it creates HOL problems and potentially kills the connection. Handling it is a PITA because there is no negotiation. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat
Received on Friday, 27 June 2014 20:55:29 UTC