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

On 30 September 2014 16:15, Matthew Kerwin <matthew@kerwin.net.au> wrote:
> On 30 September 2014 12:58, Stuart Douglas <stuart.w.douglas@gmail.com>
> wrote:
>>
>> 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.
>>
>
> But you only push resources one hop (?). E.g. origin to caching proxy.

No - its entirely legitimate to push private uncachable resources
"Caching responses that are pushed is possible based on the guidance
provided by the origin server in the Cache-Control header field.
However, this can cause issues if a single server hosts more than one
tenant. For example, a server might offer multiple users each a small
portion of its URI space."

> Also: enable_push goes from the push-receiver to the pusher. If all hops
> along the way support it, you could theoretically get end-to-end pushes
> (although I don't think such a thing is defined yet). If one hop along the
> way doesn't support it, then what's the difference?

As I wrote, the client-most hope that supports push has to
receive-and-discard-or-cache-if-permitted all the pushed resources.
That, particularly for uncachable resources, will be a non-trivial
waste of CPU and network.

-Rob

-- 
Robert Collins <rbtcollins@hp.com>
Distinguished Technologist
HP Converged Cloud

Received on Tuesday, 30 September 2014 03:38:48 UTC