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 16:17:31 -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: <1B2AF3CF-BEE3-48F0-A3B3-BFE72F3005EA@redhat.com>
To: Willy Tarreau <w@1wt.eu>

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

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