Re: HTTP/2 extensions and proxies

The idea isn't to list every extension, but rather to only have 'h2' and
'e-h2'.
We reduce this more by asserting that any endpoint sending 'e-h2' must be
able to recieve 'h2', and that any endpoint receiving 'e-h2' MUST be able
to reply with 'h2' (i.e 'e-h2' implies 'h2')

You are right that, if every extension was put in there, there would be an
exponential explosion. That would be silly.
Unfortunately "MUST NOT be silly", is apparently a difficult directive to
follow (as my wife can tell you), and better language, if possible is
useful. :)

The primary design-space constraint is that there should be zero addtional
RTTs of overhead for negotiating this stuff. That implies NPN/ALPN. Taking
another RTT for negotiation is likely a non-starter-- the cost in latency
is likely to exceed the benefit of the negotiation.
Not sticking this in NPN/ALPN suffers from potentially the same exponential
size explosion if a similar formatting is used.
-=R


On Wed, Oct 2, 2013 at 10:20 AM, Mike Bishop
<Michael.Bishop@microsoft.com>wrote:

>  ALPN identifiers are a non-starter -- it would make the list of
> identifiers explode.  If I support extensions A, B, and C then I have to
> advertise support for:****
>
> **·       **H2****
>
> **·       **H2+ExtA****
>
> **·       **H2+ExtB****
>
> **·       **H2+ExtC****
>
> **·       **H2+ExtA+ExtB****
>
> **·       **H2+ExtA+ExtC****
>
> **·       **H2+ExtB+ExtC****
>
> **·       **H2+ExtA+ExtB+ExtC****
>
> ...and the number grows exponentially as more extensions exist.  Plus
> doubled, with Gabriel & Roberto’s draft on H2 vs. H2c.****
>
> ** **
>
> Limiting extensions to things that can be ignored really bounds what
> they’re able to do.  It seems more likely we’d need to advertise support
> for extensions through SETTINGS or a new negotiation frame type, and only
> send the extension frames if the negotiation succeeded.  There still needs
> to be a way for an extension to be identified end-to-end or hop-by-hop even
> if you don’t understand it, so that an intermediary which doesn’t know
> about a given extension can know authoritatively whether it should still
> negotiate it and pass it through, or not negotiate it.****
>
> ** **
>
> -----Original Message-----
> From: Amos Jeffries [mailto:squid3@treenet.co.nz]
> Sent: Tuesday, October 1, 2013 5:59 PM
> To: Roberto Peon
> Cc: James M Snell; HTTP Working Group
> Subject: Re: HTTP/2 extensions and proxies
>
> ** **
>
> On 2/10/2013 7:11 a.m., Roberto Peon wrote:****
>
> > Let me state my preferences in order:****
>
> > A) The proxy (or server or client) advertises that it allows or ****
>
> > disallows non-standard probably via ALPN/NPN string.****
>
> >   Endpoints ignore any frame-type they don't understand.****
>
> >** **
>
> > When the proxy has advertised that it uses the standard protocol version:
> ****
>
> >    No party shall create non-standard frames which, if dropped, would **
> **
>
> > cause any desynchronization errors.****
>
> >    Proxies may drop what they see fit.****
>
> >** **
>
> > When the proxy (client/server, whatever) have advertised that it ****
>
> > allows non-standard protocol versions:****
>
> >    Cients/servers may create non-standard frames.****
>
> >    Proxies must not not modify any frame they don't understand.****
>
> ** **
>
> ** **
>
> As an implementer looking at the above there is no reason for me to write
> code that only advertises the standard version without extensions. ****
>
> If I did there would very shortly be a customer request to add something
> so I may as well solve a lot of pain and potential customer loss just
> advertising the extension support.****
>
> ** **
>
> Which brings to the problem with this one...  extensions are rarely packed
> in nice protocol name bunches. Most of the extensions to HTTP/1 have been
> single headers tacked on one at a time. Do you plan to have ALPN/NPN
> listing all the individual non-standard headers supported for each hop?
> That is what is waiting at the end of this slippery slope.****
>
> ** **
>
> ** **
>
> >** **
>
> > B) Frames which have traversed a proxy are marked as having traversed **
> **
>
> > a proxy by flipping a bit.****
>
> >   Endpoints ignore any frame-type they don't understand.****
>
> >   Endpoints receiving point-to-point frames with this bit flipped must *
> ***
>
> > ignore the frame.****
>
> >   Proxies need not examine frame contents, except to flip this bit.****
>
> >** **
>
> ** **
>
> When there are two proxies involved and only the second one understands
> the frame type. What happens?****
>
>   - at best a waste of bandwidth and CPU passing the frame along. ****
>
> Because as a hop-by-hop the second proxy knows enough to identify that it
> was not supposed to be received. In the same way responsible HTTP/1.1
> proxies deal with Expect: emitted by HTTP/1.0 hops today.****
>
> ** **
>
> What if the frame type was somebodies equivalent of Expect: or Keep-Alive:
> ?****
>
> ** **
>
> What types of proxy are expected to flip bits? not all proxies are equal
> even today. Some just take the traffic stream and relay it to an upstream
> (think load balancers, request/stream routers, tunnels, etc). ****
>
> How do these middleware types identify whether they are to flip the bit,
> ignore the bit, or drop the frame?****
>
> ** **
>
>   (C) solves all these issues by making them irrelevant with a single rule
> that applies to all endpoints. There is no restriction that frames with
> what we are calling the end-to-end bit are actually end-to-end, just that
> they are treated as if they were by hops that dont understand them.****
>
> ** **
>
> ** **
>
> > C)  Frames are marked with either hop-by-hop or end-to-end.****
>
> >   Endpoints ignore any frame-type they don't understand.****
>
> >   Proxies must examine frame contents and remove all hop-by-hop frames.*
> ***
>
> ** **
>
> Strawman here with "examine frame contents" ... "examine frame type" is
> the proposal. When the marker is in the type code itself, as proposed, they
> have to do that examining anyway to figure out whether the frame is
> supported or not. There is *zero* additional work required, and this can
> also be implemented on a read-only buffer.****
>
> ** **
>
> ** **
>
> Also, and this affects all the proposals so far;****
>
>     what happens when a frame has minor corruption in the type field value
> making it "unknown type"?****
>
> ** **
>
> Amos****
>
> ** **
>