RE: Priority inside PUSH_PROMISE frames

Emitting a PRIORITY frame from the server doesn’t make sense to begin with – it’s telling the client how to prioritize resources, by the definition of priority, but the client is going to make whatever resource allocation makes sense for its scenario.  I would expect most clients to completely ignore PRIORITY frames.

You’re right than an intelligent server probably has a layer of knowledge beyond what the protocol defines in situations like that; that’s part of why HTTP/2 priorities are strictly advisory – so the server has the freedom to apply additional intelligence.

From: Jeff Pinner [mailto:jpinner@twitter.com]
Sent: Thursday, June 12, 2014 12:40 PM
To: RUELLAN Herve
Cc: HTTP Working Group ‎[ietf-http-wg@w3.org]‎
Subject: Re: Priority inside PUSH_PROMISE frames

This isn't necessary.

The HEADERS frame has an optional priority field to avoid a race condition. PRIORITY frames cannot be sent on the stream that HEADERS is being sent on because the HEADERS frame creates the stream. If the request contains no body, the server may process and send the response before receiving any subsequent PRIORITY frames on that stream.

For PUSH_PROMISE frames, the stream is opened with the PUSH_PROMISE and processing cannot complete until a HEADERS frame containing the response metadata is received. Servers that wish to set a non-default priority can do so by sending a PRIORITY frame between the PUSH_PROMISE and the HEADERS. There is no race condition.

On Thu, Jun 12, 2014 at 12:29 PM, RUELLAN Herve <Herve.Ruellan@crf.canon.fr<mailto:Herve.Ruellan@crf.canon.fr>> wrote:
All,

Currently, when a stream is created by a PUSH_PROMISE, it has a default
priority. It depends on its associated stream and its weight is 16.  In many
case, this default priority has no impact from the client point of view and
doesn't need to be changed.

Recent work on DASH has shown interest in using HTTP/2 push for transmitting
several video segments upon receiving one client request. These video segments
are consecutive parts of the video and should be received sequentially by the
client to allow for a streaming playback of the video. A smart server will
push these video segments sequentially, notwithstanding the default
priorities.
However, the client has no way to know whether the server it is connecting
to is smart or not. To share this knowledge, the PUSH_PROMISE frame should be modified
to optionally include priority information (as is already the case for the
HEADER frame).  The client could rely on this priority information to discover
the server behaviour, and to decide whether or not sending PRIORITY frames to
correct it.

Other scenarios could take advantage of including priority information inside
PUSH_PROMISE frames. For example, a group of images can be pushed in parallel
(the default behaviour), which is useful for starting quickly a progressive
rendering of all the images belonging to a web page. This group of images can
also be pushed sequentially (with non-default priorities), which is useful to
show quickly the first images in a long list of images. In this latter case,
the PUSH_PROMISE frames would contain priority information, indicating to the
client the intended behaviour of the server.

Hervé