http: fix for handling on boot timers headers and request by franciszek-koltuniuk-red · Pull Request #48291 · nodejs/node

@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

benjamingr

@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

ShogunPanda

marco-ippolito

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

@franciszek-koltuniuk-red

mcollina

This was referenced

Jun 9, 2023

@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

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>

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 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>