maskit commented on PR #13695: URL: https://github.com/apache/trafficserver/pull/13695#issuecomment-5898776311
Thanks for checking. I'm used to TLS settings, which are fixed at handshake time, so I assumed "new connections only" was the general rule. It isn't: HTTP config is snapshotted per transaction, `proxy.config.net.*` is live, and you've shown the HTTP/2 settings are mixed. So I'm fine with the dynamic behavior as long as a mid-connection switch doesn't break open connections. I traced the transitions and found two things: 1. Inbound `create_stream()` now reads the policy twice: `_has_dynamic_stream_window()` at [L1883](https://github.com/apache/trafficserver/blob/f09c345910007db50699ec3cbc4cf8251f36ada2/src/proxy/http2/Http2ConnectionState.cc#L1883) and again at [L1920](https://github.com/apache/trafficserver/blob/f09c345910007db50699ec3cbc4cf8251f36ada2/src/proxy/http2/Http2ConnectionState.cc#L1920). If a reload lands between them and flips the result from false to true, we send a SETTINGS frame without the `_check_outgoing_settings_frame()` pre-check. If the outstanding-SETTINGS limit has been reached, that trips the `ink_assert` at L1924. The window is tiny, but the fix is to read it once into a local, as the outbound path already does at [L1759](https://github.com/apache/trafficserver/blob/f09c345910007db50699ec3cbc4cf8251f36ada2/src/proxy/http2/Http2ConnectionState.cc#L1759). 2. Switching away from policy 2 leaves open connections stuck at their last dynamic stream window. No more SETTINGS frames are sent, so `acknowledged_local_settings[INITIAL_WINDOW_SIZE]` never returns to `initial_window_size_*`. It isn't a protocol error, but those connections won't behave like fresh policy 0/1 connections. I'm OK with that if it's intended. Could you mention it in the `policy_in`/`policy_out` docs? Connection-level windows look safe in both directions: growing goes through the normal WINDOW_UPDATE path, and shrinking just drains because `restart_receiving()` holds back updates. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
