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

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.

Willy

Received on Friday, 27 June 2014 20:58:07 UTC