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

RE: Design Issue: PUSH_PROMISE and Stream Priority

From: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
Date: Fri, 26 Apr 2013 10:43:39 +0000
To: Martin Thomson <martin.thomson@gmail.com>, James M Snell <jasnell@gmail.com>
CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <6C71876BDCCD01488E70A2399529D5E516416AC5@ADELE.crf.canon.fr>

> -----Original Message-----
> From: Martin Thomson [mailto:martin.thomson@gmail.com]
> Sent: vendredi 26 avril 2013 02:17
> To: James M Snell
> Cc: ietf-http-wg@w3.org
> Subject: Re: Design Issue: PUSH_PROMISE and Stream Priority
> > Another question: do pushed streams inherit the same priority as their
> > associated "parent" streams? That is, client initiates a stream #1 to
> > the server with priority 5, server responds on that stream with two
> > PUSH_PROMISES for server-initiated streams #2 and #4... do streams #2
> > and #4 inherit the same priority as stream #1. (Please say no, Please
> > say no)
> I'm going to say yes and then make your day even worse by pointing out that
> RST_STREAM(CANCEL) on stream #1 is expected to terminate all related
> push streams, even if stream #1 is long gone.  (I'm assuming that one didn't
> sink in when you read it.)  At least with priority you can copy that state over
> when you copy over request headers (unless you want reprioritization of the
> "parent" to also reprioritize pushes, which seems mega-crazy to me).  The
> push cancellation thing is messy.

I'm seeing the problem in a slightly different way: in the current usage of SPDY, the client initiates the stream #1 by sending the HEADERS+PRIORITY frame with the FINAL flag set to half close it. Therefore, the client is unable to send a RST_STREAM on stream #1 to terminate the related push streams.
To take into account server push, the client will want to keep the stream #1 fully open until at least it is half closed by the server. This means that in HTTP/2.0, stream #1 will stay alive much longer.

Received on Friday, 26 April 2013 10:44:08 UTC

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