W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: HTTP/2 extensions and proxies

From: James M Snell <jasnell@gmail.com>
Date: Tue, 1 Oct 2013 09:42:12 -0700
Message-ID: <CABP7RbcGmPbUEYyFmsFdtQCUvq+k9W5p_Mfd227FLEUf=LB80A@mail.gmail.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
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
>>>
>>>
>>
>
Received on Tuesday, 1 October 2013 16:43:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:18 UTC