Re: HTTP/2 extensions and proxies

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.

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.

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.


B or C are potentially helpful, but, in and of themselves don't solve the
fundamental problem:

Assuming that endpoints ignore any frame-type they don't understand (which
seems required without a central registry for extensions and corresponding
increase in handshake time or exponential blowup of ALPN/NPN strings), then
the main problem is really ensuring that nothing bad happens when such
frames are ignored and that, when frames successfully traverse a proxy,
then they will continue to successfully traverse that proxy.
Thus, a means of signaling the intent of the proxy (or server, whatever) to
allow extensions/experiments to traverse (or not) is interesting.


-=R




On Tue, Oct 1, 2013 at 9:42 AM, James M Snell <jasnell@gmail.com> wrote:

> On Tue, Oct 1, 2013 at 8:48 AM, Roberto Peon <grmocg@gmail.com> wrote:
> > Uh, by that I mean that proxies are unlikely to treat either hop-by-hop
> or
> > end-to-end as special if there is no special marking for them, and that
> > instead marking that a header had been seen leads to better semantics.
>
> To make sure it's clear, what you're suggesting is that rather than
> marking a static range of frame types as being "end-to-end" vs
> "hop-by-hop" (as I suggested several months ago and Amos reiterated in
> this thread), the idea would be for an intermediary to inspect each
> frame and decide whether or not it wishes to pass the frame on or not,
> and if it does, set a flag saying, essentially, "I passed this on
> untouched". Is that accurate?
>
> While I can certainly see advantages to that approach, I'm not clear
> on why it allows for "better semantics". Please elaborate. For one,
> the marking approach could easily lead to inconsistent handling of
> extension frames across implementations and would make it impossible
> for specs to define reliable normative handling requirements.
>
> What I suggest is a variation on my original proposal:
> https://github.com/http2/http2-spec/issues/95
>
> 1. Segment a range of FRAME type codes (0x00-7F) as being
> "hop-by-hop", and a range as always end-to-end (0x80-FF), with an
> upper segment of each (20 codes from each range) designated as
> "private use" codes that cannot be registered in IANA.
>
> 2. When an endpoint encounters an unknown/unsupported hop-by-hop frame
> on Stream #0, it MUST respond with a PROTOCOL_ERROR.
>
> 3. When an endpoint encounters an unknown/unsupported hop-by-hop frame
> on a specific stream, it MUST respond with an RST_STREAM
>
> 4. When an endpoint encounters an unknown/unsupported end-to-end frame
> on Stream #0, it MUST respond with a PROTOCOL_ERROR. (The requirement
> is that End-to-End frames are *never* on Stream #0)
>
> 5. When an endpoint encounters an unknown/unsupported end-to-end frame
> on a specific stream, the endpoint MUST either pass *all* unknown
> frames through on that stream, or respond with an RST_STREAM
> terminating the stream.
>
> 6. All end-to-end frames are subject to flow control.
>
> The idea here is that extension hop-by-hop frames can only be reliably
> sent on a connection if both endpoints agree to their use. This limits
> the use of hop-by-hop extensions significantly but I don't see that as
> being a bad thing.
>
> It further requires that end-to-end frames are ALWAYS sent on a
> stream. They are never on Stream #0.
>
> Rule #6 is important because it keeps an intermediary from
> accidentally altering the semantics of a stream. For instance, let's
> suppose that a client sends a DATA frame, followed by an extension FOO
> frame, followed by a final DATA frame. The intermediary has no idea
> what the FOO frame is, what it's used for, or why it was sent. With
> Roberto's suggested approach, the intermediary would have the option
> of simply dropping the FOO frame entirely, while passing the two DATA
> frames on unchanged. What the intermediary might not be aware of,
> however, is how dropping that FOO frame could completely change the
> semantics of the DATA. The better approach is for the intermediary to
> make a strict choice of either allowing everything through untouched
> (I don't know what this is, but I'm going to let someone else
> downstream figure it out) or to reject everything (this stream
> contains things I don't understand, so just to be safe I'm going to
> reject the entire stream). That's the *only* reliably safe approach.
>
> If it's absolutely necessary for a sender to know in advance how the
> peer is going to act when encountering unknown end-to-end frames, then
> a new SETTINGS option can be defined, e.g.
>
>   SETTINGS_EXTENSION_REJECT = 0x00 = Pass thru all
>   SETTINGS_EXTENSION_REJECT = 0x01 = Reject all
>
> - James
>
>
> > -=R
> >
> >
> > On Tue, Oct 1, 2013 at 8:47 AM, Roberto Peon <grmocg@gmail.com> wrote:
> >>
> >> It is safer to mark that the unknown frame was passed through a proxy
> than
> >> to mark things as hop-by-hop and end-to-end.
> >> The former encourages proxies to filter. The latter does not.
> >> -=R
> >>
> >>
> >> On Mon, Sep 30, 2013 at 4:34 AM, Amos Jeffries <squid3@treenet.co.nz>
> >> wrote:
> >>>
> >>> On 30/09/2013 7:54 p.m., Gábor Molnár wrote:
> >>>>
> >>>> Currently, "Implementations MUST ignore frames of unsupported or
> >>>> unrecognized types.". As far as I see, the point of this is to enable
> >>>> the extension of the protocol in a backwards compatible way.
> >>>>
> >>>> But what about proxies? Should they ignore unrecognized frames too, or
> >>>> should they forward them? If they drop every unknown frame, it is not
> >>>> possible to specify end-to-end extensions. Is this constraint
> >>>> intentional? I think that end-to-end extensions would be useful, too,
> >>>> e.g. WebSockets over HTTP2 if a HTTP2 proxy does not support
> >>>> WebSockets explicitly.
> >>>
> >>>
> >>> And if they pass all unknown frames it will not be possible to develope
> >>> future hop-by-hop extensions.
> >>>
> >>> I think there needs to be a flag indicating which group the frame
> belongs
> >>> to or splitting the frame type value range into two segments.
> >>> I suggest the uppermost bit of the frame type value be set to 1 on
> >>> end-to-end frames.
> >>>
> >>> Amos
> >>>
> >>>
> >>
> >
>