W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: CONTINUATION was: #540: "jumbo" frames

From: Jason Greene <jason.greene@redhat.com>
Date: Fri, 27 Jun 2014 15:54:35 -0500
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>
Message-Id: <19255556-2B7D-4CDE-B8F9-2B8F354CFFC7@redhat.com>
To: Willy Tarreau <w@1wt.eu>

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC