-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Exceeding max header count limit closes connection after 8-10 seconds with empty response #1779
Comments
This is just old behavior for all unhandled errors. So this issue is really just a feature request to add another error. Before, all errors were lazily caught as timeout errors and timeout happens roughly after 10 seconds (8-12 seconds) |
@uNetworkingAB I understand, Since uWebsockets enforces On that same note, regarding the old timeout behavior, A response indicating the timeout instead of an empty response also helps consumers greatly. Let me know what you think of this and whether there are any plans to change this 👍 |
It should be a new error. Btw, you can't signal timeout in HTTP - there is no "push" you must wait for a request so timing out has to be "silent". |
Got it,
One doubt here regarding uWebsockets (feel free to correct me here), If a client sends a request, and we know in the framework that an unhandled error has occurred - why not send a response with |
Aha, the timeouts I talk about are the general way "any unhandled error" is caught. But the point of timeouts are not for a request that was made but never responded to, but rather as keep-alive timeout. But in any case - adding an error here will fix this. |
It really is just this fix 388e2b3 |
Here is output:
👍 |
@uNetworkingAB That's great, thanks for this! Just one suggestion here, can we include what exactly was breached i.e The reason for this is that for requests which are responded by uWebsockets.js directly - the application code won't be able to record this (correct me if there is a way - I do not see this in the docs). I understand having this setup to inform the application might be a design decision (could be a performance hit) which requires further thinking, but for now the above would help. Let me know |
Instead of having a palette of errors it can be a palette of functions returning the error. But this would need more than just you wanting it ;) |
Got it, I understand 👍 |
Hey,
We see that there are two variables that dictate header limits:
When
UWS_HTTP_MAX_HEADERS_SIZE
is breached, the uWebsockets.js app (v20.48.0
) returns a431
within milliseconds (for a request header just above the limit), as expected, and closes the connection. But whenUWS_HTTP_MAX_HEADERS_COUNT
is breached, the app doesn't respond for 8-10 seconds and then sends empty response & closes the connection without returning a4xx
, This causes reverse proxy (NGINX) to return 502s.This seems problematic as a bad client request (with too many headers) results in a 5xx instead of a 4xx and takes a few seconds to reply instead of being instant (on local experimentation, it seems to not be affecting other valid requests sent - but on a large scale, we are not sure if it affects others). I see other consumers that have faced similar issue (Ref)
Steps to replicate:
server
Version:
github:uNetworking/uWebSockets.js#v20.48.0
request
Output:
The text was updated successfully, but these errors were encountered: