Re: HTTP/2 extensions and proxies

+1...

This discussion needs to be split into two distinct elements:

1. Identification of hop-by-hop vs. end-to-end frames.

2. Handling of unknown frame types.

For 1, I believe the suggestion that I made originally (that was
reiterated in this thread) is appropriate. Specifically, We designate
the highest order bit in the type value as the "end-to-end" bit. (if
set, the frame type is end-to-end). Additional constraints ought to
include: (a) end-to-end frames MUST be sent on a stream and (b)
end-to-end frames MUST be subject to flow control.

For 2, I believe the handling I've already described is the most
appropriate. Allowing an intermediary to blindly remove individual
unknown frames from a stream is very dangerous, especially if the
intermediary has no idea why those frames exist.

- James

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
>
>

Received on Wednesday, 2 October 2013 17:38:06 UTC