Stream cancellation by transport #485
Comments
martinthomson
added
design
|
Hmm... So if I host netconf over QUIC, I need to invent a new error code for this? That's definitely going to need some guidance to app protocol designers. |
|
The alternative is to say that they can all use the same error code, but the application layer might not bind state to a specific stream in a way that cancellation even makes sense. Once again, we encounter a hazard imposed by only having one application. |
|
The hazard with that split is that it also quietly eliminates the ability to consider a stream (application) error as fatal to the connection. If you send me malformed HTTP frames, I might want to stop talking to you. If application errors can't go in the CONNECTION_CLOSE, then I can't communicate why. On the other hand, if we leave them partitioned with the app at the low end, we could say that only app codes can be in RST_STREAM and that frame has a smaller error space as a result. |
|
@MikeBishop, I thought of that. The application would signal its errors in the affected stream then use a new transport code (APPLICATION_ERROR) for the CONNECTION_CLOSE. Or something like that. |
|
...without reliable delivery of said application error, no? The problem is that stream data is inherently lossy in the presence of errors. If we want to change that, fine, but it seems like an even bigger change. |
|
If we create a recommendation to follow what Google already does for conection-level errors, it's not an issue. That is, they retransmit the last packet verbatim, which could include the RST_STREAM frame. |
mnot
changed the title
|
Based on discussion on #211, I have updated this to be an architectural issue and added a one-line summary to the OP. |
mnot
added
the
has-consensus
Should we prohibit the transport from resetting streams?
@ekr asked which code a server might use to cancel streams that exceed a revised limit after 0-RTT in #479.
My initial response was CANCELLED, which I'm adding in #467. However on reflection I think that might be a category error. The application protocol should be the one to cancel things and we should use the HTTP-defined HTTP_REQUEST_CANCELLED instead.
The reason being twofold:
On general principles, the transport shouldn't be cancelling streams without first consulting the application layer; what if the transport cancelled stream 3 (or maybe stream 1)? To the transport that's not special
Signaling the ability to retry is easier at the application layer. At the transport layer the only way to distinguish between retryable and not is to ask whether any bytes were passed to the application layer. At the application layer, even if bytes were delivered, the application might still be able to cancel without side effects.
Errors at the transport layer should probably be fatal to the connection as a whole. If you look at the error codes, there are few that aren't as a result of some sort of fatal error.
That suggests a split. Errors in TLS or the transport go in CONNECTION_CLOSE. Errors in the application layer go in RST_STREAM. The nice partitioning that @MikeBishop did can be thrown out and we can fold transport and TLS into the same space (or split that, I care not).
The text was updated successfully, but these errors were encountered: