Uh oh!
There was an error while loading. Please reload this page.
http: fix for handling on boot timers headers and request - #48291
http: fix for handling on boot timers headers and request #48291nodejs-github-bot merged 3 commits into
Conversation
nodejs-github-bot
commented
Jun 2, 2023
Review requested:
|
ShogunPanda
commented
Jun 2, 2023
In general LGTM. Can you please add a test? |
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 : |
franciszek-koltuniuk-red
commented
Jun 2, 2023
This issue is observed since "refactor headersTimeout and requestTimeout logic" #41263 |
ShogunPanda
commented
Jun 2, 2023
@nodejs/libuv Do you have any opinion on this? Is there a way to mock uv_hrtime? |
bnoordhuis
commented
Jun 2, 2023
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
commented
Jun 2, 2023
Yeah, definitely too much for a simple verification. Are we good in landing this without a test? |
benjamingr
left a comment
There was a problem hiding this comment.
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.
jasnell
left a comment
There was a problem hiding this comment.
LGTM but I agree that additional comments would be helpful.
franciszek-koltuniuk-red
commented
Jun 5, 2023
Code commented |
590d23f to
ae3f8caCompareThis 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
ae3f8ca to
fc3c854Comparefranciszek-koltuniuk-red
commented
Jun 7, 2023
I had to re-edit commits messages, to fulfill the commit message check |
nodejs-github-bot
commented
Jun 8, 2023
I see that checks failed but these fails are not related to this change:
to summarize the test failed due to errors unrelated to this change. What can I do to process this pull request? btw. |
nodejs-github-bot
commented
Jun 14, 2023
nodejs-github-bot
commented
Jun 14, 2023
franciszek-koltuniuk-red
commented
Jun 19, 2023
What is blocking this change from being merged? |
I was completely wrong. Nevermind. Landed :) |
nodejs-github-bot
commented
Jun 19, 2023
Landed in 8e710c9 |
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 who can decide to backport this fix to LTS branches? |
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>
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>
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>
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>
This change is a fix for handling headersTimeout and requestTimeout
that causes unexpected behavior if the HTTP server is started on boot:
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