Re: PUSH_PROMISE at invalid times

On Tue, Aug 20, 2013 at 1:47 AM, Martin Thomson <martin.thomson@gmail.com>wrote:

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


I totally agree to punish broken implementations. I've written many network
applications and those broken ones always bother me a lot.
My point is the interactions between fully compliant implementations which
is PUSH_PROMISE after sending RST_STREAM. Sorry if my original post is not
clear about it.
I saw a commit to address this issue, so my concern is completely cleared.
Thank you very much!

Best regards,

Tatsuhiro Tsujikawa