W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

RE: SETTINGS frame - not documented as peer-to-peer only

From: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
Date: Tue, 30 Sep 2014 09:18:36 +0000
To: Stuart Douglas <stuart.w.douglas@gmail.com>, Martin Thomson <martin.thomson@gmail.com>
CC: Robert Collins <robertc@robertcollins.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <6C71876BDCCD01488E70A2399529D5E53BE74E1D@ADELE.crf.canon.fr>
These settings are just peer to peer, and it's possible to take advantage of them even if they are not supported end to end.

For example, in the configuration:
Client -> proxy -> server

The client can set SETTINGS_ENABLE_PUSH to false, the proxy can set it to true.
The server will push resources to the proxy, which can:
- Cancel the pushed resources
- Accept the pushed resources and cache them: it will be able to respond directly when the client will be asking them.

Hervé.

> -----Original Message-----
> From: Stuart Douglas [mailto:stuart.w.douglas@gmail.com]
> Sent: mardi 30 septembre 2014 04:58
> To: Martin Thomson
> Cc: Robert Collins; HTTP Working Group
> Subject: Re: SETTINGS frame - not documented as peer-to-peer only
> 
> I think the real issue here is that SETTINGS_ENABLE_PUSH and the
> proposed SETTINGS_WEBSOCKET_CAPABLE are really end to end settings
> rather than just peer to peer. You need both endpoints and all
> intermediaries to support them for them for them to be used, and at the
> moment we have no way of discovering this. All you can really do is
> attempting a push / websocket connection and hope it works.
> 
> All other settings make sense as peer to peer settings, but I really
> don't think these two do.
> 
> Stuart
> 
> Martin Thomson wrote:
> > On 29 September 2014 14:17, Robert Collins<robertc@robertcollins.net>
> wrote:
> >> When reading the websockets draft, it occured to me that perhaps I
> >> misunderstand SETTINGS. AIUI it is peer to peer, not end to end.
> >
> > How else could this possibly work?
> >

Received on Tuesday, 30 September 2014 09:19:11 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:10 UTC