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

Re: #539: Priority from server to client

From: David Krauss <potswa@gmail.com>
Date: Wed, 16 Jul 2014 07:04:34 +0800
Cc: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>, Mark Nottingham <mnot@mnot.net>, Mike Bishop <Michael.Bishop@microsoft.com>, HTTP Working Group <ietf-http-wg@w3.org>, Johnny Graettinger <jgraettinger@chromium.org>
Message-Id: <804D9E07-118E-46E9-96D4-32AE0A8ABF97@gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>

On 2014Ė07Ė16, at 1:30 AM, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 15 July 2014 09:41, RUELLAN Herve <Herve.Ruellan@crf.canon.fr> wrote:
>> 2. We allow the server to express its priority intentions concerning pushed streams. We could add new optional priority fields to the PUSH_PROMISE frame, that would convey the server intent.
> For a server that is declaring its priority, why can't it just apply
> the prioritization it deems best until the client says otherwise?  Is
> there some advantage to the server being able to diverge from the
> default, but have the client know about the specifics of the
> divergence?

There is no way to prevent servers from diverging from the default, itís an inevitable application-level optimization.

There is a disadvantage to keeping the initial prioritization secret from the client, because then it does not know when to expect the information. A client could reasonably assume a worst-case scenario. Itís an unnecessary adversarial relationship.

Think of it this way: rather than encourage negotiation, PUSH_PROMISE /PRIORITY lays the serverís cards on the table, to establish a friendly consensus with a client that may not wish to dictate everything.

This applies to option (1) and the text in the pull request (https://github.com/hruellan/http2-spec/commit/bd8052410a5b29a0089f16b721d399105ddee48b ), not to option (2) and server-sent PRIORITY frames. Although I was initially in favor of (2) as well, such behavior seems very application-specific. Upload prioritization commands should be in the ALPN extension domain; this might include PRIORITY frames per se or maybe not.
Received on Tuesday, 15 July 2014 23:05:12 UTC

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