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

Received on Wednesday, 2 October 2013 00:59:47 UTC