W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

Re: Design Issue: PUSH_PROMISE and Stream Priority

From: James M Snell <jasnell@gmail.com>
Date: Sat, 27 Apr 2013 13:30:34 -0700
Message-ID: <CABP7RbeMmCCVHPT5XxiTbrrRs4QBGeQfvMY1_YLasvpZnJMCYA@mail.gmail.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, RUELLAN Herve <Herve.Ruellan@crf.canon.fr>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
I honestly cannot imagine any scenario where it would be useful or
desirable to allow the server to set a priority for pushed streams. My
preference would be for us to say that only client-initiated streams
have a priority. If we want to leave the door open later on, we can
say that priority on server-initiated streams is undefined and out of
scope rather than saying it's not allowed at all.

On Fri, Apr 26, 2013 at 11:46 AM, Roberto Peon <grmocg@gmail.com> wrote:
> Sorry I'm so slow-- internet connectivity is absolutely crud where I am
> right now.
> What will the client do with the information a push_promise?
>  The headers, etc. are obvious--
> That data will prevent the client from creating another (redundant) request
> for the resource/
> If the client is given priority information with a push_promose, perhaps
> this might cause the client to send a reprio message immediately to whatever
> the client wants, potentially before the server begins sending bytes or
> creates the stream/reads the bytes. This assumes that the server even
> *knows* what the priority is at that point, which it may not.
> ... and, really, that is the only thing I can see the client doing with that
> information. Does anyone see anything else it might do with it?
> does anyone think this is likely to be useful?
> On Fri, Apr 26, 2013 at 11:35 AM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>> On 26 April 2013 09:27, James M Snell <jasnell@gmail.com> wrote:
>> > For this there are several possible solutions:
>> >
>> >     A. We can simply say PUSH_PROMISE streams have no priority.
>> >     B. We can say that PUSH_PROMISE streams inherit the priority of
>> > their parent, client-initiated stream
>> >     C. We can allow the server to use HEADERS+PRIORITY or a new
>> > Reprioritization Frame to establish the priority of a pushed stream.
>> That seems like a fair taxonomy.
>> A is not possible.  There is no such thing as no priority.  Default
>> priority, perhaps.  At the point that you have to contend with
>> choosing between two streams, then you have prioritization.
Received on Saturday, 27 April 2013 20:31:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:12 UTC