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

http: fix for handling on boot timers headers and request #48291

Conversation

franciszek-koltuniuk-red
Copy link
Contributor

@franciszek-koltuniuk-red franciszek-koltuniuk-red commented Jun 2, 2023

This change is a fix for handling headersTimeout and requestTimeout
that causes unexpected behavior if the HTTP server is started on boot:

  • the connections to the server can be closed immediately
    with the status HTTP 408

This issue usually happens in IoT or embedded devices where
the reference timestamp (returned by uv_hrtime()) is counted since boot
and can be smaller than the headersTimeout or the requestTimeout value.

Additionally added performance improvement to process the list of
connection only if one of the timers should be processed

@nodejs-github-bot
Copy link
Collaborator

Review requested:

  • @nodejs/http
  • @nodejs/net

@nodejs-github-bot nodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. http_parser Issues and PRs related to the HTTP Parser dependency or the http_parser binding. needs-ci PRs that need a full CI run. labels Jun 2, 2023
@ShogunPanda
Copy link
Contributor

In general LGTM. Can you please add a test?

@franciszek-koltuniuk-red
Copy link
Contributor Author

franciszek-koltuniuk-red commented Jun 2, 2023

I try to prepare a test case for this, but the issue is observed when the now is less than headersTimeout or requestTimeout where now is :
const uint64_t now = uv_hrtime();
I don't know how to create test like test/parallel/test-http-server-request-timeout-interrupted-body.js to fulfill this requirement in all environments
The value for headersTimeout or requestTimeout is limited to Integer see validation requestTimeout and headersTimeout

@franciszek-koltuniuk-red
Copy link
Contributor Author

This issue is observed since "refactor headersTimeout and requestTimeout logic" #41263

@ShogunPanda
Copy link
Contributor

I don't know how to create test like test/parallel/test-http-server-request-timeout-interrupted-body.js to fulfill this requirement in all environments

@nodejs/libuv Do you have any opinion on this? Is there a way to mock uv_hrtime?

@bnoordhuis
Copy link
Member

Is there a way to mock uv_hrtime?

In libuv? No.1 You can of course refactor node's code to make hrtime calls pluggable but that's overkill for a simple fix like this.

1 Or rather, you can overload clock_gettime/mach_absolute_time/mach_continuous_time/etc. through LD_PRELOAD/DYLD_PRELOAD but that's probably not what you mean.

@ShogunPanda
Copy link
Contributor

Yeah, definitely too much for a simple verification.
The next run on the connectionsCheckingInterval would kill connections anyway.

Are we good in landing this without a test?

Copy link
Member

@benjamingr benjamingr left a comment

Choose a reason for hiding this comment

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

If we can't test this - it would be good to at least add a comment to why this change is being made in the code.

Copy link
Member

@jasnell jasnell left a comment

Choose a reason for hiding this comment

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

LGTM but I agree that additional comments would be helpful.

@franciszek-koltuniuk-red franciszek-koltuniuk-red changed the title Headers request timers fix http: fix for handling on boot timers headers and request Jun 4, 2023
@franciszek-koltuniuk-red
Copy link
Contributor Author

additional comments would be helpful.

Code commented

This change is a fix for handling headersTimeout and requestTimeout
that causes unexpected behavior if the HTTP server is started on boot:

 - the connections to the server can be closed immediately
   with the status HTTP 408

This issue usually happens on IoT or embedded devices where
the reference timestamp (returned by uv_hrtime()) is counted since boot
and can be smaller than the headersTimeout or the requestTimeout value.

Additionally added performance improvement to process the list of
connection only if one of the timers should be processed
@franciszek-koltuniuk-red
Copy link
Contributor Author

I had to re-edit commits messages, to fulfill the commit message check

@marco-ippolito marco-ippolito added the request-ci Add this label to start a Jenkins CI on a PR. label Jun 8, 2023
@github-actions github-actions bot removed the request-ci Add this label to start a Jenkins CI on a PR. label Jun 8, 2023
@nodejs-github-bot
Copy link
Collaborator

Copy link
Member

@mcollina mcollina left a comment

Choose a reason for hiding this comment

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

lgtm

@franciszek-koltuniuk-red
Copy link
Contributor Author

franciszek-koltuniuk-red commented Jun 13, 2023

I see that checks failed but these fails are not related to this change:

  • node-test-commit — tests failed due to dependency on node-test-commit-osx, node-test-commit-windows-fanned, node-test-binary-windows-js-suites
  • node-test-commit-osx — tests failed due to:
    10:45:24 Failed to write /Users/iojs/build/workspace/node-test-commit-osx/nodes/osx1015/out/Release/obj/gen/node_snapshot.cc 10:45:24 make[2]: *** [/Users/iojs/build/workspace/node-test-commit-osx/nodes/osx1015/out/Release/obj/gen/node_snapshot.cc] Error 1
    see: Failed to write /Users/iojs/build/workspace/node-test-commit-osx/nodes/osx1015/out/Release/obj/gen/node_snapshot.cc
  • node-test-commit-windows-fanned — tests failed due to dependency on node-test-binary-windows-js-suites
  • node-test-pull-reques — tests failed due to dependency on node-test-commit
  • node-test-binary-windows-js-suites — tests failed due to:
    10:28:19 Can't clean tmpdir: C:\workspace\node-test-binary-windows-js-suites\node\test\.tmp.168 10:28:19 Files blocking: [ 'node.heapsnapshot' ] 10:28:19 10:28:19 C:\workspace\node-test-binary-windows-js-suites\node\test\common\tmpdir.js:68 10:28:19 throw e; 10:28:19 ^ 10:28:19 10:28:19 Error: EBUSY: resource busy or locked, rmdir '\\?\C:\workspace\node-test-binary-windows-js-suites\node\test\.tmp.168'
    see: Can't clean tmpdir: C:\workspace\node-test-binary-windows-js-suites\node\test.tmp.168

to summarize the test failed due to errors unrelated to this change.

What can I do to process this pull request?

btw.
I think that it would be desirable to backport this change to stable branches

@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot
Copy link
Collaborator

@franciszek-koltuniuk-red
Copy link
Contributor Author

What is blocking this change from being merged?

@tniessen tniessen added author ready PRs that have at least one approval, no pending requests for changes, and a CI started. commit-queue-squash Add this label to instruct the Commit Queue to squash all the PR commits into the first one. labels Jun 19, 2023
@ShogunPanda ShogunPanda added the commit-queue Add this label to land a pull request using GitHub Actions. label Jun 19, 2023
@ShogunPanda
Copy link
Contributor

ShogunPanda commented Jun 19, 2023

I tried to add the labels to merge this. But since CI is locked for upcoming security releases I'm not sure if this will affected as well.

I was completely wrong. Nevermind. Landed :)

@nodejs-github-bot nodejs-github-bot removed the commit-queue Add this label to land a pull request using GitHub Actions. label Jun 19, 2023
@nodejs-github-bot nodejs-github-bot merged commit 8e710c9 into nodejs:main Jun 19, 2023
61 checks passed
@nodejs-github-bot
Copy link
Collaborator

Landed in 8e710c9

RafaelGSS pushed a commit that referenced this pull request Jul 3, 2023
This change is a fix for handling headersTimeout and requestTimeout
that causes unexpected behavior if the HTTP server is started on boot:

 - the connections to the server can be closed immediately
   with the status HTTP 408

This issue usually happens on IoT or embedded devices where
the reference timestamp (returned by uv_hrtime()) is counted since boot
and can be smaller than the headersTimeout or the requestTimeout value.

Additionally added performance improvement to process the list of
connection only if one of the timers should be processed

PR-URL: #48291
Reviewed-By: Robert Nagy <ronagy@icloud.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Paolo Insogna <paolo@cowtech.it>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
@RafaelGSS RafaelGSS mentioned this pull request Jul 3, 2023
@franciszek-koltuniuk-red
Copy link
Contributor Author

franciszek-koltuniuk-red commented Jul 13, 2023

@RafaelGSS who can decide to backport this fix to LTS branches?

Ceres6 pushed a commit to Ceres6/node that referenced this pull request Aug 14, 2023
This change is a fix for handling headersTimeout and requestTimeout
that causes unexpected behavior if the HTTP server is started on boot:

 - the connections to the server can be closed immediately
   with the status HTTP 408

This issue usually happens on IoT or embedded devices where
the reference timestamp (returned by uv_hrtime()) is counted since boot
and can be smaller than the headersTimeout or the requestTimeout value.

Additionally added performance improvement to process the list of
connection only if one of the timers should be processed

PR-URL: nodejs#48291
Reviewed-By: Robert Nagy <ronagy@icloud.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Paolo Insogna <paolo@cowtech.it>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Ceres6 pushed a commit to Ceres6/node that referenced this pull request Aug 14, 2023
This change is a fix for handling headersTimeout and requestTimeout
that causes unexpected behavior if the HTTP server is started on boot:

 - the connections to the server can be closed immediately
   with the status HTTP 408

This issue usually happens on IoT or embedded devices where
the reference timestamp (returned by uv_hrtime()) is counted since boot
and can be smaller than the headersTimeout or the requestTimeout value.

Additionally added performance improvement to process the list of
connection only if one of the timers should be processed

PR-URL: nodejs#48291
Reviewed-By: Robert Nagy <ronagy@icloud.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Paolo Insogna <paolo@cowtech.it>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
ruyadorno pushed a commit that referenced this pull request Sep 10, 2023
This change is a fix for handling headersTimeout and requestTimeout
that causes unexpected behavior if the HTTP server is started on boot:

 - the connections to the server can be closed immediately
   with the status HTTP 408

This issue usually happens on IoT or embedded devices where
the reference timestamp (returned by uv_hrtime()) is counted since boot
and can be smaller than the headersTimeout or the requestTimeout value.

Additionally added performance improvement to process the list of
connection only if one of the timers should be processed

PR-URL: #48291
Reviewed-By: Robert Nagy <ronagy@icloud.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Paolo Insogna <paolo@cowtech.it>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
@ruyadorno ruyadorno mentioned this pull request Sep 10, 2023
ruyadorno pushed a commit that referenced this pull request Sep 13, 2023
This change is a fix for handling headersTimeout and requestTimeout
that causes unexpected behavior if the HTTP server is started on boot:

 - the connections to the server can be closed immediately
   with the status HTTP 408

This issue usually happens on IoT or embedded devices where
the reference timestamp (returned by uv_hrtime()) is counted since boot
and can be smaller than the headersTimeout or the requestTimeout value.

Additionally added performance improvement to process the list of
connection only if one of the timers should be processed

PR-URL: #48291
Reviewed-By: Robert Nagy <ronagy@icloud.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Paolo Insogna <paolo@cowtech.it>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author ready PRs that have at least one approval, no pending requests for changes, and a CI started. c++ Issues and PRs that require attention from people who are familiar with C++. commit-queue-squash Add this label to instruct the Commit Queue to squash all the PR commits into the first one. http_parser Issues and PRs related to the HTTP Parser dependency or the http_parser binding. needs-ci PRs that need a full CI run.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

10 participants