Lachlan

@janbartel yes I converted it back to a draft. Maybe this PR is something we want to consider for Jetty 12.

closing in favor of #10750 for Jetty 12

PR #4931 ensures that we try closing all open sessions before closing the `Connectors`. We should also ensure we do not accept any new websocket connections once we start the...

@joakime do you think is this something that we actually need to support? it doesn't mention anything about situations like this in the JSR.

@sbordet This seems to be the problematic situation. 1. The encoder sends `EncodedFieldSection` with non-zero required insert count. 2. Reading is abandoned before this `EncodedFieldSection` is received. 3. The decoder...

@sbordet do you know where we can receive the HTTP/3 stream cancellation notification so we can call QPACK.

@dlwss this line in your stacktrace `org.eclipse.jetty.websocket.common.JettyWebSocketRemoteEndpoint.sendBytes(JettyWebSocketRemoteEndpoint.java:65)` the blocking `sendBytes` method is being used. There is another method on `JettyWebSocketRemoteEndpoint` called `void sendBytes(ByteBuffer data, WriteCallback callback)` which takes a `WriteCallback`...

Note: Jetty 9, Jetty 10, and Jetty 11 are all now at End of Community Support. So you should strongly consider upgrading to Jetty 12. See: * https://github.com/jetty/jetty.project/issues/7958 * https://github.com/jetty/jetty.project/issues/10485

But just means that the connection was closed when you were trying to write. The WebSocket implementation has been completely re-written for the newer versions of Jetty, I would expect...

@gregw I don't think this issue is asking to be able to stream the parts which have been received, but to publish parts to be sent into a `Request.Content`. But...