Re: Stream State and PRIORITY Frames

[Scott Mitchell <[e-mail]>]

Thanks for responses everyone. There seems to be recognition that the
specification lacks clarity but there also seems to be momentum behind
"Option 1".

This leads to the practical concern of bounding the amount of memory
committed to streams in this state. SETTINGS_MAX_CONCURRENT_STREAMS limits
number of streams in "open" or "half-closed", but the specification doesn't
(to my knowledge) define a way to limit the number of "reserved" streams or
"idle"/"closed" streams which have had only PRIORITY frames exchanged. The
specification allows for implementations to discard PRIORITY more or less
at their discretion [3], but limiting "reserved" streams is another issue. "
SETTINGS_ENABLE_PUSH" is limited to 0 or 1 [4] so there is no way for a
client to advertise how many "reserved" streams it is willing to accept.
What are the practical approaches folks have taken to address these issues?

[3] https://tools.ietf.org/html/rfc7540#section-5.3.4
> The retention of priority information for streams that are not counted
toward the limit set by SETTINGS_MAX_CONCURRENT_STREAMS could create a
large state burden for an endpoint. Therefore, the amount of prioritization
state that is retained MAY be limited.
[4] https://tools.ietf.org/html/rfc7540#section-6.5.2

> The initial value is 1, which indicates that server push is permitted.  Any value other than 0 or 1 MUST be treated as a connection error (Section 5.4.1 <https://tools.ietf.org/html/rfc7540#section-5.4.1>) of type PROTOCOL_ERROR.



On Tue, Jan 17, 2017 at 4:42 AM, Cory Benfield <[e-mail]> wrote:

>
> On 17 Jan 2017, at 08:38, Benedikt Christoph Wolters <
> [e-mail]> wrote:
>
> This question reminds me of a similiar issue we had a while ago at
> mitmproxy: https://github.com/mitmproxy/mitmproxy/issues/1498
>
> As far as I understand this, sending PRIORITY does not initiate a
> stream or change the stream state.
> HEADERS and PUSH_PROMISE initiate a stream. PRIORITY can be sent and
> received in any stream state.
>
>
> In fact, I think it’s the same issue. Scott linked to https://github.com/
> summerwind/h2spec/pull/67, which is referenced from and opened by the
> same person who opened https://github.com/h2o/h2o/pull/1136, which links
> to https://github.com/mitmproxy/mitmproxy/issues/1824, which is related
> to https://github.com/mitmproxy/mitmproxy/issues/1498 because both cases
> were sites deployed behind Fastly.
>
> For those who want background and don’t want to follow all those links,
> mitmproxy bumped into problems with sites deployed behind Fastly. mitmproxy
> encountered these because it was forwarding on traffic from Firefox, which
> would on connection-setup send a whole bunch of PRIORITY frames. hyper-h2
> (which powers mitmproxy’s HTTP/2 support) would allow this. h2o would not.
>
> The crux of the discussion boils down to a few apparently contradictory
> sections in the specification. Scott linked to the first two:
>
> Section 5.1.1:
>
> - The first use of a new stream identifier implicitly closes all streams
> in the “idle” state that may have been initiated by that peer with a
> lower-valued stream identifier.
> - An endpoint that receives an unexpected stream identifier must respond
> with a connection error of type PROTOCOL_ERROR.
>
> *However*, there are a few other notes. The first thing to note is that
> the PRIORITY frame does not transition a stream out of the idle state. A
> stream that has only had PRIORITY frames sent on it is still in the IDLE
> state. That means that the Firefox-style priority setup (sending priority
> for stream IDs 1, 3, 5, and 7 immediate after the preamble) would have the
> effect of immediately closing streams 1, 3, and 5, if section 5.1.1
> applied. This is not what most people expect.
>
> More importantly, though, section 5.1.1 says this:
>
> - The identifier of a newly established stream MUST be numerically greater
> than all streams that the initiating endpoint has opened or reserved.
> This governs streams that are opened using a HEADERS frame and streams that
> are reserved using PUSH_PROMISE.
>
> This is not absolutely clear, but it seems to suggest that implementations
> may establish a stream with an ID lower than streams that have had PRIORITY
> frames sent on them. Put another way, it seems to suggest that only HEADERS
> and PUSH_PROMISE frames affect the lowest-acceptable stream ID. That seems
> to me to suggest that PRIORITY frames are not expected to force-close all
> streams with lower IDs that are in the idle state.
>
> As an implementers note, I have found it much more helpful to think of
> PRIORITY frames not as frames that are sent on a stream, but as frames that
> are implicitly sent on stream zero and are just tagged with a stream ID.
> PRIORITY frames ignore basically all restrictions on stream behaviour: they
> can be sent on idle streams, on closed streams. In practice, they can
> basically be sent whenever, and except for the case where they establish a
> loop in the priority tree must basically always be accepted.
>
> Cory
>