Re: PUSH_PROMISE at invalid times

On 17 August 2013 06:06, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> wrote:
> The alternative approach is always process PUSH_PROMISE
> and its header block, thus changes stream state and compression
> state. After that if the receiver thinks that it should be rejected,
> then issue RST_STREAM to the promised stream ID.

We've made it a general policy that we'll be really harsh on badly
behaving implementations.  Being tolerant of rubbish just hides
implementation issues.  We've all seen how much damage has done to
HTTP/1.1.

In this case, the only thing that is missing - at least in the cited
text - is another mention that it is possible that you can receive a
PUSH_PROMISE after sending RST_STREAM.  That's already in the stream
states section, but there's no mention in the PUSH_PROMISE section
that was added.

Received on Monday, 19 August 2013 16:48:13 UTC