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

Re: 6.6 PUSH_PROMISE (Re: draft-ietf-httpbis-http2-08 / 5.1. Stream States)

From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 19 Dec 2013 10:20:22 -0800
Message-ID: <CABkgnnUUEy6ygzirpyYT8ue5BJLQ+Z=O4-8NT_jdgo59DrOihQ@mail.gmail.com>
To: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
Cc: HTTPBIS working group mailing list <ietf-http-wg@w3.org>
On 19 December 2013 09:08, Kari Hurtta <hurtta-ietf@elmme-mailer.org> wrote:
> | Similarly, a receiver MUST treat the receipt of a PUSH_PROMISE that
> | promises an illegal stream identifier (Section 5.1.1) (that is, an
> | identifier for a stream that is not currently in the "idle" state) as
> | a connection error (Section 5.4.1) of type PROTOCOL_ERROR, unless the
> | receiver recently sent a RST_STREAM frame to cancel the associated
> | stream (see Section 5.1).
> If recipient is sent RST_STREAM then it goes to "closed" state, not
> to "idle" state.

I think that the "unless..." here offers an option that doesn't make
sense.  The original problem, if I remember correctly, was that there
was a chance that a promise could arrive on a stream that was reset.

We deal with that elsewhere already:

An endpoint might receive a PUSH_PROMISE frame after it sends
RST_STREAM. PUSH_PROMISE causes a stream to become "reserved". The
RST_STREAM does not cancel any promised stream. Therefore, if promised
streams are not desired, a RST_STREAM can be used to close any of
those streams.

Thus, I'm going to remove the "unless..." here and avoid confusion.
While I'm there, I'll clarify that latter statement, because - having
now re-read it - it's a little ambiguous.
Received on Thursday, 19 December 2013 18:20:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:20 UTC