Re: #539: Priority from server to client

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