- From: David Krauss <potswa@gmail.com>
- Date: Tue, 22 Jul 2014 13:42:48 +0800
- To: Johnny Graettinger <jgraettinger@chromium.org>
- Cc: Mark Nottingham <mnot@mnot.net>, RUELLAN Herve <Herve.Ruellan@crf.canon.fr>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
That doesn’t make any sense. The need for a push isn’t identified by a client. The currently foreseen “garden variety” implementation does not interface PUSH_PROMISE streams to the application at all, but only to the user-agent cache. That’s why pushing only works on cacheable resources. The server identifies the need for the push and it should have the right to send it at whatever rate is appropriate. The client should have the right to know what rate the transfer is supposed to be occurring, for example to know what to down-prioritize when QoS is suffering on a real-time stream from the same server. On 2014–07–21, at 11:16 PM, Johnny Graettinger <jgraettinger@chromium.org> wrote: > The garden implementation path is that a client sends a PRIORITY frame on a push stream when it locally identifies a need (and prioritization) for that resource, and not until then. Thus having the server advertise applied priority appears useful only to a client which has an opinion about priority that differs from the server, yet is willing to be overruled by the server anyway. > > Please correct me if I'm wrong, but it's not clear to me that there's a real use case out there that's enabled by this.
Received on Tuesday, 22 July 2014 05:43:36 UTC