Add a mechanism to close a session with an error message #60
Conversation
draft-ietf-webtrans-http3.md
Outdated
| Upon learning about the session being terminated, the endpoint MUST stop | ||
| sending new datagrams and reset all of the streams associated with the session. | ||
| An WebTransport session over HTTP/3 is considered terminated when either | ||
| endpoint closes the stream associated with the CONNECT request that initiated |
There was a problem hiding this comment.
- What happens when one endpoint sends a RESET_STREAM? Is it a protocol violation, or "unclean" session termination?
- What happens when one endpoint sends a STOP_SENDING on the CONNECT stream?
There was a problem hiding this comment.
Those are all included in the "closed" term.
There was a problem hiding this comment.
Should we be more explicit that either peer closes the write half of the stream or you think it's implied?
There was a problem hiding this comment.
I reworded this to make it explicit that either peer closing it in either way means it's terminated.
As discussed on the mailing list, neither 62- nor 64-bit error code sare Web-safe, and 32 bits should be enough for most applications.
|
@DavidSchinazi @ekinnear @afrind Updated the PR; please take another look. |
Co-authored-by: David Schinazi <DavidSchinazi@users.noreply.github.com>
|
I think I addressed all issues; please tell me if I'm missing anything, if not, I'll merge this soon. |
|
|
||
| : A UTF-8 encoded error message string provided by the application closing the | ||
| connection. The message takes up the remainer of the capsule, and its | ||
| length MUST NOT exceed 1024 bytes. |
There was a problem hiding this comment.
Any particular reason for the choice of length? Just trying to stay under QUIC minimum sizes?
There was a problem hiding this comment.
Not in particular, just trying to place some bound on the string length, and 1024 seemed like a reasonable number.
There was a problem hiding this comment.
Maybe add a sentence explaining the limit?
| CLOSE_WEBTRANSPORT_SESSION, the stream MUST be reset with code | ||
| H3_MESSAGE_ERROR. The recipient MUST close the stream upon receiving a FIN. | ||
| If the sender of CLOSE_WEBTRANSPORT_SESSION does not receive a FIN after some | ||
| time, it SHOULD send STOP_SENDING on the CONNECT stream. |
There was a problem hiding this comment.
So this isn't an error? Or we think it might be, but we're trying to be more gentle?
Or we expect it to actually happen in real life if there's a high enough RTT?
There was a problem hiding this comment.
Maybe this bit of text belongs above (around line 369) and be made generic to the case when a peer sends a FIN (without CLOSE_WEBTRANSPORT_SESSION) as well?
There was a problem hiding this comment.
Well, there isn't really an "error" when it comes to closing things (since you're closing them anyways). But yes, in general, (0, "") is the close code unless specified otherwise.
Co-authored-by: David Schinazi <DavidSchinazi@users.noreply.github.com>
|
|
||
| : A UTF-8 encoded error message string provided by the application closing the | ||
| connection. The message takes up the remainer of the capsule, and its | ||
| length MUST NOT exceed 1024 bytes. |
There was a problem hiding this comment.
Maybe add a sentence explaining the limit?
Co-authored-by: David Schinazi <DavidSchinazi@users.noreply.github.com>
Also reword that paragraph a bit
Fixes #41.