- 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