- From: Jason Greene <jason.greene@redhat.com>
- Date: Fri, 27 Jun 2014 16:17:31 -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:57 PM, Willy Tarreau <w@1wt.eu> wrote: > On Fri, Jun 27, 2014 at 03:54:35PM -0500, Jason Greene wrote: >> >> 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. > > Yeah that's true, but my point is not to advocate for CONTINUATION frames, > rather to ensure that they're so useless that nobody uses them unless > everything is under total control on the whole chain. Then it will not > be that much of a problem for people taking the risk to pass extra-large > headers. They're already facing trouble today anyway. Fair enough. If they aren’t fixed I think we will end up just disabling support for them by default, and if enabled disallow coalescing. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat
Received on Friday, 27 June 2014 21:18:27 UTC