mozilla
Consider mapping unknown error code to `HttpNoError`
Error codes of the format 0x1f * N + 0x21 for non-negative integer values of N are reserved to exercise the requirement that unknown error codes be treated as equivalent to H3_NO_ERROR (Section 9).
https://datatracker.ietf.org/doc/html/rfc9114#section-8.1
Say that the remote closes a connection with CloseReason::Application(0) where 0 is any error code we don't understand, should we be mapping this error to neqo_http3::Error::HttpNoError in neqo_http3?
https://github.com/mozilla/neqo/blob/c1679d89b5c3192429ff1bc56ed21e10dc699eef/neqo-http3/src/lib.rs#L378-L402
Raised by @valenting in Matrix.
I'm understanding this the following way:
Yes, all unknown error codes should be mapped to H3_NO_ERROR.
Error codes of the 0x1f * N + 0x21 format are reserved from being used as codes in error code extensions (section 9 - extensions to http/3). They should instead be randomly chosen with a small probability when we'd want to send H3_NO_ERROR (so instead of 0x100), I guess the reasoning being that by introducing that randomness we make sure others are interpreting unknown error codes correctly.
Implementations SHOULD select an error code from this space with some probability when they would have sent H3_NO_ERROR.
https://datatracker.ietf.org/doc/html/rfc9114#section-8.1-3
I'm not sure if we're already doing that, but I guess not since we don't map unknown codes correctly. It would be weird if we checked others on that but don't implement it ourselves.
So I think this would actually entail two things: ONE, making sure we handle unknown error codes correctly and TWO, sometimes sending a 0x1f * N + 0x21 error instead of 0x100.
I do wonder if other h3 implementations actually do TWO though, because then we would probably have noticed earlier that we're not mapping unknown errors correctly. That being the reason for even implementing TWO, to "force" others to map the codes.
