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

On 30 September 2014 13:38, Robert Collins <robertc@robertcollins.net>
wrote:

> 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."
> ​
>
>
That doesn't make it any less a single-hop push, or a single-hop setting.
You don't "need both endpoints and all intermediaries" for them to be used
(useful?) in *all* cases, just this one.


​
> ​
> ​
> ​

​
> > 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.
>
>
Indeed. If it's that worrying, when your muxer gets a client that doesn't
support push, just send an upstream SETTINGS_ENABLE_PUSH(0). If that client
goes away, re-send the setting with (1).  If anything, this point furthers
the case that this isn't and cannot be an end-to-end setting, as Stuart
suggested, because end-to-end implies 1:1, and this is a 1:n situation.

If I were replying to your sub-thread (and we weren't past WGLC) I'd have
said: add a third value to SETTINGS_ENABLE_PUSH to say "only cacheable
resources", and/or introduce a per-stream setting (which I suppose
manifests as a HEADERS flag and/or extension frame) to toggle pushes in
response to a particular request. Note that you're well within your rights
to draft such an extension right now. If it's good, and gains support, it
could be pushed out pretty close to the core spec and maybe even get into
some implementations.


-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/