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

Re: HTTP/2 extensions and proxies

From: Roberto Peon <grmocg@gmail.com>
Date: Tue, 1 Oct 2013 08:48:44 -0700
Message-ID: <CAP+FsNdq6rEFn2VLLLU6xtPaDUunq-bFKeC4rVGo-U9fYpwKRw@mail.gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
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.

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 15:49:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:18 UTC