W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2016

Re: Recursive HTTP/2 Push

From: Daniel Stenberg <daniel@haxx.se>
Date: Sun, 7 Feb 2016 16:06:10 +0100 (CET)
To: Simone Bordet <simone.bordet@gmail.com>
cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <alpine.DEB.2.20.1602071550480.4476@tvnag.unkk.fr>
On Sun, 7 Feb 2016, Simone Bordet wrote:

> The user agent requests recursive.html (say with stream_id=3) and Jetty 
> pushes both recursive.css and recursive.png in the following way:
> PUSH_PROMISE (stream_id=3, promised_stream_id=2)
> PUSH_PROMISE (stream_id=2, promised_stream_id=4)
> Both Chrome and Firefox accepts and use these pushes, but nghttp2
> reports a protocol error, citing 7540, section 6.6:
> "PUSH_PROMISE frames MUST only be sent on a peer-initiated stream that
> is in either the "open" or "half-closed (remote)" state."

My reading of the spec also says that a server would be wrong sending such 
frames and that a client should reject such frames (as it isn't legal in that 
state) with a PROTOCOL_ERROR.

> Can someone clarify if HTTP/2 really intended to forbid recursive pushes and 
> why ?

I can't remember the exact reasoning, but it seems clear to me that we 
want(ed) servers only to push resources on streams the client has asked for. 
"Pushed responses are always associated with an explicit request from the 
client" (from 8.2.1)

But is there a particular reason to insist on sending the push promise on 
stream_id 2 in the second push and not just make it on stream_id 3?


  / daniel.haxx.se
Received on Sunday, 7 February 2016 15:06:38 UTC

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