W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Re: PUSH_PROMISE at invalid times

From: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Date: Wed, 21 Aug 2013 00:24:52 +0900
Message-ID: <CAPyZ6=J4cUSmWfebpOE3BW=dQy9mqoiqB0t+5DQ-ry_9vVLUZA@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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
Received on Tuesday, 20 August 2013 15:25:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC