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

Recursive HTTP/2 Push

From: Simone Bordet <simone.bordet@gmail.com>
Date: Sun, 7 Feb 2016 13:04:26 +0100
Message-ID: <CAFWmRJ3vg+3kBPKyLCgGGBNjVi61qS0_jyYKAAv9QAzjNhd4ug@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>

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.

    <link rel="stylesheet" href="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

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
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

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