Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider mapping unknown error code to HttpNoError #2577

Open
mxinden opened this issue Apr 9, 2025 · 2 comments
Open

Consider mapping unknown error code to HttpNoError #2577

mxinden opened this issue Apr 9, 2025 · 2 comments

Comments

@mxinden
Copy link
Collaborator

mxinden commented Apr 9, 2025

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?

neqo/neqo-http3/src/lib.rs

Lines 378 to 402 in c1679d8

impl From<AppError> for Error {
fn from(error: AppError) -> Self {
match error {
0x100 => Self::HttpNoError,
0x101 => Self::HttpGeneralProtocol,
0x103 => Self::HttpStreamCreation,
0x104 => Self::HttpClosedCriticalStream,
0x105 => Self::HttpFrameUnexpected,
0x106 => Self::HttpFrame,
0x107 => Self::HttpExcessiveLoad,
0x108 => Self::HttpId,
0x109 => Self::HttpSettings,
0x10a => Self::HttpMissingSettings,
0x10b => Self::HttpRequestRejected,
0x10c => Self::HttpRequestCancelled,
0x10d => Self::HttpRequestIncomplete,
0x10f => Self::HttpConnect,
0x110 => Self::HttpVersionFallback,
0x200 => Self::QpackError(QpackError::DecompressionFailed),
0x201 => Self::QpackError(QpackError::EncoderStream),
0x202 => Self::QpackError(QpackError::DecoderStream),
_ => Self::HttpInternal(0),
}
}
}

Raised by @valenting in Matrix.

@omansfeld
Copy link
Collaborator

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.

@larseggert
Copy link
Collaborator

This might be something to ask on the quicdev slack. (Ping me if you need an invite.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants