Re: HTTP/2 extensions and proxies

Why not just define an optional capabilities exchange mechanism on
Channel 0?

Eliot

On 10/2/13 7:20 PM, Mike Bishop 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
>
>  
>