<p><pre><code> Instead, the official method is that the browser can
signal the server to cancel a push with a so-called
RST_STREAM reply to a PUSH_PROMISE.
</code></pre>
while this sounds reasonable it's actually strange.
Basically a PUSH_PROMISE has two stream id's. One with the stream it is sent over and one with the promised stream. Actually the RST should target the promised stream.<p>another thing which his article never actually mentions is when to send the actual PUSH_PROMISE.
And the problem extends further that the most reasonable moment to send it is before the actual html, but the DATA (should not always as explained in his article) sent directly before the actual html. This actually makes it really hard to have a good implementation since you actually need lots of state and priorities to get the best behavior.<p>I'm extremly skeptical of http/2. we go from a stateless protocol to a extremly stateful one, just to fix some things, but we raise a lot of new ones.