RE: Design Issue: PUSH_PROMISE and Stream Priority



> -----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
> 
[snip]
> 
> > 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.

Hervé.

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