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

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