RE: HTTP/2 extensions and proxies

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