8000 QUIC: ngx_quic_set_error() function. by arut · Pull Request #708 · nginx/nginx · GitHub
[go: up one dir, main page]

Skip to content

QUIC: ngx_quic_set_error() function. #708

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

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

arut
Copy link
Contributor
@arut arut commented May 25, 2025

The function sets QUIC error unless it was set before. After that the error is logged. Cryptographic handshake errors are properly formatted.

The change allows to simplify error generation in the QUIC code. Also, it eliminates the necessity to explicitly log QUIC errors. Each call of ngx_quic_set_error() now receives a well-formatted error message that is both logged and later sent to the client.

Additionally, qc->error_ftype is now detetced automatically based on the currently processed frame.

@arut arut requested a review from pluknet May 25, 2025 12:19
@arut arut force-pushed the quic-set-error branch from db425e4 to c6254c5 Compare May 26, 2025 13:12
@arut
Copy link
Contributor Author
arut commented May 26, 2025

Fixed BoringSSL build.

@arut
Copy link
Contributor Author
arut commented May 26, 2025

Examples of logging a handshake crypto error.
OpenSSL:

2025/05/26 17:08:29 [info] 2567783#0: *1 handshake error (QUIC: 368, SSL: error:0A000458:SSL routines::tlsv1 unrecognized name) while handling frames, client: 127.0.0.1, server: 127.0.0.1:8980

BoringSSL:

2025/05/26 16:58:34 [info] 2564256#0: *1 handshake error (QUIC: 368, SSL: error:10000458:SSL routines:OPENSSL_internal:TLSV1_ALERT_UNRECOGNIZED_NAME) while handling frames, client: 127.0.0.1, server: 127.0.0.1:8980

Copy link
Contributor
@pluknet pluknet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left some generic comments.

Comment on lines +138 to +139
ngx_quic_set_error(c, NGX_QUIC_ERR_TRANSPORT_PARAMETER_ERROR,
"invalid initial_source_connection_id");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This contradicts the "client sent invalid ..." idiom used for logging client errors.

@@ -520,9 +504,9 @@ ngx_quic_close_connection(ngx_connection_t *c, ngx_int_t rc)
* to terminate the connection immediately.
*/

if (qc->error == 0 && rc == NGX_ERROR) {
qc->error = NGX_QUIC_ERR_INTERNAL_ERROR;
qc->error_app = 0;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see how qc->error_app is now reset.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see how qc->error_app is now reset.

Now errors are never reset after being set once. So there's no need to reset error_app,.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

qc->error_app does not need to be reset. If qc->error in unchanged, then qc->error_app is unchanged as well.


qc = ngx_quic_get_connection(c);

if (qc->error) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if (qc->error != NGX_QUIC_ERR_NO_ERROR) ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the difference? We treat 0 as the default value and do no direct initialiazation of qc->error.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Somehow I overlooked the code line in a hurry, no need to change this.

The comment is actually about comparing err with 0 slightly below.
For style reasons, it could be changed to if (err == NGX_QUIC_ERR_NO_ERROR)
just because after that you compare it with real errors.

}

if (err >= NGX_QUIC_ERR_CRYPTO_ERROR
&& err <= NGX_QUIC_ERR_LAST_CRYPTO_ERROR)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe, define NGX_QUIC_ERR_LAST_CRYPTO_ERROR as the first invalid value (0x200) and test for < here?

Copy link
Contributor Author
@arut arut May 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed we use a similar notation with NGX_HTTP_LAST_2XX, NGX_HTTP_LAST_3XX etc. It will be confusing though if they'll come up with an actual error 0x200 in future versions.

@@ -109,6 +109,7 @@
#define NGX_QUIC_ERR_NO_VIABLE_PATH 0x10

#define NGX_QUIC_ERR_CRYPTO_ERROR 0x100
#define NGX_QUIC_ERR_LAST_CRYPTO_ERROR 0x1ff
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It may be a good idea to shorten the name to NGX_QUIC_ERR_CRYPTO_LAST

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if it's a good idea. Also, see the http macros above for reference.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm afraid NGX_HTTP_LAST_2XX is not a good example.
The reasoning behind this is to keep a common prefix with NGX_QUIC_ERR_CRYPTO_ERROR.
Well, I won't insist, it's up to you.

Comment on lines +1237 to +1238
if (qc->error == 0) {
qc->error_ftype = frame.type;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have to admit that this change (in particular, to propagate the NGX_QUIC_FT_ACK value) is quite counterintuitive, it may deserve a separate commit with explanation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok

@@ -621,6 +605,47 @@ ngx_quic_close_connection(ngx_connection_t *c, ngx_int_t rc)
}


void
ngx_quic_set_error(ngx_connection_t *c, ngx_uint_t err, const char *reason)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't only sets, but also logs.
So why not ngx_quic_error().

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest we switch to just setting at this point. I will switch logging to debug and give it some though.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That sounds good.

Previously qc->error_ftype was only set in ngx_quic_handle_ack_frame_range()
while handling an ACK frame and ignored in other frame handlers.  Meanwhile
RFC 9000 specifies that a CONNECTION_CLOSE frame should carry the frame type
which triggered the error.

To simplify setting error frame type, qc->error_ftype is now set
automatically to the currently processed frame type.  If no error was
generated while handling a frame, the value is reset.
@arut
Copy link
Contributor Author
arut commented May 29, 2025

Made frame type change a separate patch. Also, removed error logging from ngx_quic_set_error() and left it where it is now. Let's target this separately.

Here's simple grep from h3 tests:

2025/05/29 19:42:50 [debug] 2728325#0: *102 quic error app c:513 r:"stream error"
2025/05/29 19:42:50 [debug] 2728325#0: *102 quic error c:0 r:"connection is closing, packet discarded"
2025/05/29 19:42:50 [debug] 2728325#0: *102 quic error c:0 r:"connection is closing, packet discarded"
2025/05/29 19:42:50 [debug] 2728325#0: *102 quic error c:0 r:"connection is closing, packet discarded"
2025/05/29 19:42:50 [debug] 2728325#0: *102 quic error c:0 r:"connection is closing, packet discarded"
2025/05/29 19:42:50 [debug] 2728325#0: *145 quic error app c:263 r:"stream error"
2025/05/29 19:42:50 [debug] 2728325#0: *145 quic error c:0 r:"connection is closing, packet discarded"
2025/05/29 19:42:50 [debug] 2728325#0: *145 quic error c:0 r:"connection is closing, packet discarded"
2025/05/29 19:42:50 [debug] 2728325#0: *145 quic error c:0 r:"connection is closing, packet discarded"
2025/05/29 19:42:50 [debug] 2728325#0: *145 quic error c:0 r:"connection is closing, packet discarded"
2025/05/29 19:42:50 [debug] 2728325#0: *145 quic error c:0 r:"connection is closing, packet discarded"
2025/05/29 19:42:50 [debug] 2728325#0: *162 quic error app c:263 r:"stream error"
2025/05/29 19:42:50 [debug] 2728325#0: *162 quic error c:0 r:"connection is closing, packet discarded"
2025/05/29 19:42:50 [debug] 2728325#0: *162 quic error c:0 r:"connection is closing, packet discarded"
2025/05/29 19:42:50 [debug] 2728325#0: *162 quic error c:0 r:"connection is closing, packet discarded"
2025/05/29 19:42:50 [debug] 2728325#0: *162 quic error c:0 r:"connection is closing, packet discarded"
2025/05/29 19:42:53 [debug] 2728334#0: *1 quic error app c:256 r:"reached maximum number of requests"
2025/05/29 19:42:58 [debug] 2728334#0: *10 quic error app c:256 r:"reached maximum number of requests"
2025/05/29 19:42:58 [debug] 2728334#0: *10 quic error c:0 r:"connection is closing, packet discarded"

@arut arut force-pushed the quic-set-error branch from c6254c5 to 0e3b1f8 Compare May 29, 2025 15:47
The function sets QUIC error unless it was set before.  Previously, a new
error always reset the old error.  Now the original error stays unchanged
for logging and sending to client.
@arut arut force-pushed the quic-set-error branch from 0e3b1f8 to 77c0829 Compare May 29, 2025 15:50
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

Successfully merging this pull request may close these issues.

2 participants
0