Which stream error code for violating SETTINGS_MAX_CONCURRENT_STREAMS?

[bradfitz]

"5.1.2 Stream Concurrency" says about SETTINGS_MAX_CONCURRENT_STREAMS:

"Endpoints MUST NOT exceed the limit set by their peer. An endpoint that receives a HEADERS frame that causes their advertised concurrent stream limit to be exceeded MUST treat this as a stream error (Section 5.4.2)"

But which stream error code should be used? Almost all other references to stream errors in the spec say "treated as a stream error of type XXX"

[bradfitz]

Also, if this is a stream error, what happens if the client has a CONTINUATION already in flight right behind the current-streams-violating HEADERS frame? The server would then return a stream error to the HEADERS frame, and then see the CONTINUATION frame that's not associated with an in-progress header block.

I suppose a server should maintain enough state to remember that it sent a stream error on that stream ID and simply ignore any following CONTINUATION frames instead of returning a connection error?

[grmocg]

The server knows that a continuation frame is coming as it is flagged in
the HEADERS frame.

Regardless, to ensure against corrupting the compression state, even if it
is thrown out, all HEADERS/CONTINUATION data must go through the
compression context unless you're closing the connection. This is even true
for stream IDs that are not in a valid state (though I'd hope in those
cases that the receiver would close the connection after immediately
sending an error).

On Sun, Nov 23, 2014 at 9:21 AM, Brad Fitzpatrick notifications@github.com
wrote:

Also, if this is a stream error, what happens if the client has a
CONTINUATION already in flight right behind the current-streams-violating
HEADERS frame? The server would then return a stream error to the HEADERS
frame, and then see the CONTINUATION frame that's not associated with an
in-progress header block.

I suppose a server should maintain enough state to remember that it sent a
stream error on that stream ID and simply ignore any following CONTINUATION
frames instead of returning a connection error?

—
Reply to this email directly or view it on GitHub
#649 (comment).

[bradfitz]

@grmocg, good point. My tests don't cover the case of a CONTINUATION having valuable compression context needed for future valid streams. I will update the test suite I'm building.

[mnot]

Discussed on-list; let's go with #652.