Re: #540: "jumbo" frames

On Wed, Jun 25, 2014 at 01:00:51PM -0700, Martin Thomson wrote:
> On 25 June 2014 12:30, Patrick McManus <pmcmanus@mozilla.com> wrote:
> > I don't think that's the case at all. un-acked extensions are limited that
> > way because you can't change the semantics of the protocol.. but once you
> > ack something you can do anything you like - including changing framing to
> > look like websockets via use one of the R bits (as an example). Go bootstrap
> > h3 that way if you feel so inclined to write an extension like that.
> >
> > but maybe I have that wrong -(our extension text is brand new afterall) and
> > extensions are meant to preclude such hackery which seems odd - given they
> > are essentially a hackery escape hatch that already acknowledges the ability
> > to change semantics of existing elements. If that's true there is always the
> > alpn method of proving this can work - because I really don't think it can
> > work and leave h2 responsive.
> 
> You have it right.  Once you get mutual agreement to use an extension,
> that extension only needs to worry about the synchronization point at
> which you change anything and everything.  Here's a basic strawman:
> 
> New setting X, 0 = off (initial), 1 = on.  Once a setting has been set
> to "on" on both sides and been acknowledged, you can enable the use of
> the reserved bits, exactly as PHK has described.  If a peer uses the
> extension prior to both acknowledging the settings and sending their
> own setting enabling the setting, you are entitled to treat that as an
> error.

The issue I'm having with the extension is very simple : I'm implementing
an intermediary which will have to adapt to both sides which disagree on
their extensions. It's the same as adapting the Connection header when one
side is 1.0 while the other one is 1.1 for example, or ensuring that one
does not use chunked-encoding when the other side does not support it.

Willy

Received on Wednesday, 25 June 2014 20:08:35 UTC