H2 transport conformant with RFC 9113 regarding #553
Conversation
|
|
||
| ioSession.getLock().lock(); | ||
| try { | ||
| if (countActiveLocalInitiated() >= remoteConfig.getMaxConcurrentStreams()) { |
There was a problem hiding this comment.
@arturobernalg Imagine being a user who wants to push 10 messages to the client being completely unaware of the MAX_CONCURRENT_STREAMS limit imposed by the client and getting some of those messages dropped with some obscure "Outbound stream limit reached" message. What would be your reaction?
There was a problem hiding this comment.
@ok2c I reworked the patch so we never drop user traffic because of the peer’s MAX_CONCURRENT_STREAMS.
There was a problem hiding this comment.
@arturobernalg so, the MAX_CONCURRENT_STREAMS does not apply to the server pushed streams, as before?
There was a problem hiding this comment.
@arturobernalg so, the
MAX_CONCURRENT_STREAMSdoes not apply to the server pushed streams, as before?
@ok2c You’re right to call this out. MAX_CONCURRENT_STREAMS does apply to server-initiated streams. my bad
There was a problem hiding this comment.
@arturobernalg so, the
MAX_CONCURRENT_STREAMSdoes not apply to the server pushed streams, as before?@ok2c You’re right to call this out. MAX_CONCURRENT_STREAMS does apply to server-initiated streams. my bad
@arturobernalg You are trying to brute force a fix on an API that simply does not have enough flexibility to support the protocol requirements. As I said before a proper solution to this issue is not possible without an extensive refactoring of the H2 protocol handling code.
arturobernalg
force-pushed
the
SETTINGS_MAX_CONCURRENT_STREAMS
branch
from
1af104d to
1d2eccf
Compare
arturobernalg
force-pushed
the
SETTINGS_MAX_CONCURRENT_STREAMS
branch
2 times, most recently
from
4ff944e to
686f30e
Compare
Do not count reserved/idle push streams toward concurrency. Refuse on the first HEADERS that would activate a promised stream when active inbound streams ≥ peer limit; emit RST_STREAM(REFUSED_STREAM). Keep push() unchanged (no limit at reservation time).
arturobernalg
force-pushed
the
SETTINGS_MAX_CONCURRENT_STREAMS
branch
from
e7517fa to
70a7373
Compare
2 participants
It introduces directional enforcement inside AbstractH2StreamMultiplexer:
Locally-initiated streams are gated by the peer’s advertised MAX_CONCURRENT_STREAMS.
Remotely-initiated streams exceeding our advertised limit are immediately refused with RST_STREAM(REFUSED_STREAM).
The same inbound check applies to PUSH_PROMISE promised streams.
After applying remote SETTINGS, we request session output so queued commands progress when the peer raises the limit.
Implementation is contained to the multiplexer (no new controller class). Active stream counting ignores terminated streams. Flow control logic remains untouched.TREAM) Add tests for inbound headers, outbound gating, and push-promise refusal; nudge queued opens on SETTINGS ACK