HTTP-31: Reserved Error codes

[gloinul]

Section 6.2:

Recipients of unknown stream types MAY abort reading of the stream with an error code of H3_STREAM_CREATION_ERROR or a reserved error code (Section 8.1), but MUST NOT consider such streams to be a connection error of any kind.

So Section 8.1 does not explain what "reserved errror code" is. The only thing I found in that section is the formula for numbers that are equivalent to NO_ERROR which doesn't make sense to me in this context of clearly an error. Is there somewhere else that should be referenced or more explanation needed?

[MikeBishop]

Yes, this is referring to the set of error codes which are "reserved to exercise the requirement that unknown error codes be treated as equivalent to H3_NO_ERROR." An unrecognized stream type could be a real extension which the recipient doesn't support, or might be a GREASE type. Because of that, it seems appropriate to potentially use the GREASE error codes in response to such streams.

[gloinul]

Isn't it problematic for an HTTP/3 endpoint that receives a for it unknown stream type to abort it and respond H3_NO_ERROR. To me that looks potentially problematic as it might indicate something worked okay if that extension have the behavior of receiving a block of data and then close down the stream? Or should any of this extension anyway be negotiated using SETTINGS so this should never be an issue as the peer should know through that SETTINGS exchange what the peer is capable of?

[LPardue]

Since the unknown stream has to be ignored, I tend to think of the grease error codes as no-known-error.

As a general principle, endpoints shouldn't rely on error codes to determine too much. The error code sender is a liberty to be as specific or non-specific as it chooses.

[MikeBishop]

+1. An extension that relied on knowing whether the receiver processed it needs to define a mechanism for the peer to acknowledge whatever state change is there. We've taken a fairly steady stance that the application layer can't rely on transport acknowledgement as proof of application-layer processing. If the sender finishes sending the stream before it receives the STOP_SENDING, it might not ever see the error code depending on the transport implementation.

[larseggert]

@gloinul do you still require changes after these explanations?

[gloinul]

No, I don't require changes. I still think there are a significant inconsistency to us "no-known-error" or as the actual code says "No Error" for something that is in fact a known error. Even if one select to be less specific there are other error codes that would be more correct.

[larseggert]

OK, I am closing this now. If an editor feels like they want to address @gloinul's final comment above with an editorial PR, they can still do so.