Re: HTTP/2 extensions and proxies

On 3/10/2013 6:37 a.m., James M Snell wrote:
> +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


For those objecting, in addition to the above. Keep in mind that "end" 
has a flexible definition.

A proxy MAY generate or remove an end-to-end frame IF (and _only_ if) is 
fully supports the frames feature and has full understanding of the 
consequences of doing so.

For example DATA frames are end-to-end yet a proxy MAY erase some 
received by buffering and aggregating the payloads into larger DATA 
frames sent.

And alternative way of thinking about it is a drop-by-default / 
pass-by-default bit embeded in the frame type code. No fancy behaviour 
necessary, just obey the flag if specific rules are unknown.

Amos

> On Wed, Oct 2, 2013 at 10:20 AM, 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
>>
>>

Received on Thursday, 3 October 2013 09:35:34 UTC