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

Re: HTTP/2 extensions and proxies

From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
Date: Tue, 1 Oct 2013 10:37:40 +0200
Message-ID: <2503c63ba69a6f49fff8760c8f2944e5.squirrel@arekh.dyndns.org>
To: "Amos Jeffries" <squid3@treenet.co.nz>
Cc: ietf-http-wg@w3.org

Le Lun 30 septembre 2013 13:34, Amos Jeffries a écrit :
> 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.

However it would be a should at most since if you require a security node
to pass on blindly stuff it does not understand the requirement will just
be ignored.

> I think there needs to be a flag indicating which group the frame
> belongs to

There is definitely a need for frames to specify their actual destination,
and the content of those frames should be protected accordingly (ie enough
shared info other nodes know to whom the frame should be routed, and
evaluate if they want to authorise the routing, but actual content not
shared with every node only by emitter and destination)

-- 
Nicolas Mailhot
Received on Tuesday, 1 October 2013 08:38:18 UTC

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