- From: Simone Bordet <simone.bordet@gmail.com>
- Date: Sun, 7 Feb 2016 13:04:26 +0100
- To: HTTP Working Group <ietf-http-wg@w3.org>
Hi, I would like to ask for a clarification about recursive pushes. The example: a recursive.html page, which links a recursive.css, which references a recursive.png image via the url() directive. recursive.html: <html> <head> <link rel="stylesheet" href="recursive.css" /> </head> </html> recursive.css body { background-image: url("recursive.png"); } 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." >From the RFC wording, it really seems that nghttp2 is right and that Jetty, Chrome and Firefox have a non standard behavior (probably inherited from their SPDY implementation): the second push is not a peer-initiated stream (even considering a pushed stream a "fake" peer-initiated stream, it is not in the "open" or "half-closed (remote)" state). Can someone clarify if HTTP/2 really intended to forbid recursive pushes and why ? Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
Received on Sunday, 7 February 2016 12:04:55 UTC