undici 7.12.0 → 7.14.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -440,13 +440,14 @@ This behavior is intentional for server-side environments where CORS restriction
440
440
  * https://fetch.spec.whatwg.org/#garbage-collection
441
441
 
442
442
  The [Fetch Standard](https://fetch.spec.whatwg.org) allows users to skip consuming the response body by relying on
443
- [garbage collection](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Memory_Management#garbage_collection) to release connection resources. Undici does not do the same. Therefore, it is important to always either consume or cancel the response body.
443
+ [garbage collection](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Memory_Management#garbage_collection) to release connection resources.
444
444
 
445
445
  Garbage collection in Node is less aggressive and deterministic
446
446
  (due to the lack of clear idle periods that browsers have through the rendering refresh rate)
447
447
  which means that leaving the release of connection resources to the garbage collector can lead
448
448
  to excessive connection usage, reduced performance (due to less connection re-use), and even
449
449
  stalls or deadlocks when running out of connections.
450
+ Therefore, __it is important to always either consume or cancel the response body anyway__.
450
451
 
451
452
  ```js
452
453
  // Do
@@ -459,7 +460,15 @@ for await (const chunk of body) {
459
460
  const { headers } = await fetch(url);
460
461
  ```
461
462
 
462
- The same applies for `request` too:
463
+ However, if you want to get only headers, it might be better to use `HEAD` request method. Usage of this method will obviate the need for consumption or cancelling of the response body. See [MDN - HTTP - HTTP request methods - HEAD](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/HEAD) for more details.
464
+
465
+ ```js
466
+ const headers = await fetch(url, { method: 'HEAD' })
467
+ .then(res => res.headers)
468
+ ```
469
+
470
+ Note that consuming the response body is _mandatory_ for `request`:
471
+
463
472
  ```js
464
473
  // Do
465
474
  const { body, headers } = await request(url);
@@ -469,13 +478,6 @@ await res.body.dump(); // force consumption of body
469
478
  const { headers } = await request(url);
470
479
  ```
471
480
 
472
- However, if you want to get only headers, it might be better to use `HEAD` request method. Usage of this method will obviate the need for consumption or cancelling of the response body. See [MDN - HTTP - HTTP request methods - HEAD](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/HEAD) for more details.
473
-
474
- ```js
475
- const headers = await fetch(url, { method: 'HEAD' })
476
- .then(res => res.headers)
477
- ```
478
-
479
481
  #### Forbidden and Safelisted Header Names
480
482
 
481
483
  * https://fetch.spec.whatwg.org/#cors-safelisted-response-header-name
@@ -620,11 +622,11 @@ and `undici.Agent`) which will enable the family autoselection algorithm when es
620
622
 
621
623
  Undici aligns with the Node.js LTS schedule. The following table shows the supported versions:
622
624
 
623
- | Version | Node.js | End of Life |
624
- |---------|-------------|-------------|
625
- | 5.x | v18.x | 2024-04-30 |
626
- | 6.x | v20.x v22.x | 2026-04-30 |
627
- | 7.x | v24.x | 2027-04-30 |
625
+ | Undici Version | Bundled in Node.js | Node.js Versions Supported | End of Life |
626
+ |----------------|-------------------|----------------------------|-------------|
627
+ | 5.x | 18.x | ≥14.0 (tested: 14, 16, 18) | 2024-04-30 |
628
+ | 6.x | 20.x, 22.x | ≥18.17 (tested: 18, 20, 21, 22) | 2026-04-30 |
629
+ | 7.x | 24.x | ≥20.18.1 (tested: 20, 22, 24) | 2027-04-30 |
628
630
 
629
631
  ## License
630
632
 
@@ -169,14 +169,38 @@ This message is published after the client has successfully connected to a serve
169
169
  ```js
170
170
  import diagnosticsChannel from 'diagnostics_channel'
171
171
 
172
- diagnosticsChannel.channel('undici:websocket:open').subscribe(({ address, protocol, extensions, websocket }) => {
172
+ diagnosticsChannel.channel('undici:websocket:open').subscribe(({
173
+ address, // { address: string, family: string, port: number }
174
+ protocol, // string - negotiated subprotocol
175
+ extensions, // string - negotiated extensions
176
+ websocket, // WebSocket - the WebSocket instance
177
+ handshakeResponse // object - HTTP response that upgraded the connection
178
+ }) => {
173
179
  console.log(address) // address, family, and port
174
180
  console.log(protocol) // negotiated subprotocols
175
181
  console.log(extensions) // negotiated extensions
176
182
  console.log(websocket) // the WebSocket instance
183
+
184
+ // Handshake response details
185
+ console.log(handshakeResponse.status) // 101 for successful WebSocket upgrade
186
+ console.log(handshakeResponse.statusText) // 'Switching Protocols'
187
+ console.log(handshakeResponse.headers) // Object containing response headers
177
188
  })
178
189
  ```
179
190
 
191
+ ### Handshake Response Object
192
+
193
+ The `handshakeResponse` object contains the HTTP response that upgraded the connection to WebSocket:
194
+
195
+ - `status` (number): The HTTP status code (101 for successful WebSocket upgrade)
196
+ - `statusText` (string): The HTTP status message ('Switching Protocols' for successful upgrade)
197
+ - `headers` (object): The HTTP response headers from the server, including:
198
+ - `upgrade: 'websocket'`
199
+ - `connection: 'upgrade'`
200
+ - `sec-websocket-accept` and other WebSocket-related headers
201
+
202
+ This information is particularly useful for debugging and monitoring WebSocket connections, as it provides access to the initial HTTP handshake response that established the WebSocket connection.
203
+
180
204
  ## `undici:websocket:close`
181
205
 
182
206
  This message is published after the connection has closed.
@@ -27,7 +27,7 @@ For detailed information on the parsing process and potential validation errors,
27
27
  * **clientFactory** `(origin: URL, opts: Object) => Dispatcher` (optional) - Default: `(origin, opts) => new Pool(origin, opts)`
28
28
  * **requestTls** `BuildOptions` (optional) - Options object passed when creating the underlying socket via the connector builder for the request. It extends from [`Client#ConnectOptions`](/docs/docs/api/Client.md#parameter-connectoptions).
29
29
  * **proxyTls** `BuildOptions` (optional) - Options object passed when creating the underlying socket via the connector builder for the proxy server. It extends from [`Client#ConnectOptions`](/docs/docs/api/Client.md#parameter-connectoptions).
30
- * **proxyTunnel** `boolean` (optional) - By default, ProxyAgent will request that the Proxy facilitate a tunnel between the endpoint and the agent. Setting `proxyTunnel` to false avoids issuing a CONNECT extension, and includes the endpoint domain and path in each request.
30
+ * **proxyTunnel** `boolean` (optional) - For connections involving secure protocols, Undici will always establish a tunnel via the HTTP2 CONNECT extension. If proxyTunnel is set to true, this will occur for unsecured proxy/endpoint connections as well. Currently, there is no way to facilitate HTTP1 IP tunneling as described in https://www.rfc-editor.org/rfc/rfc9484.html#name-http-11-request. If proxyTunnel is set to false (the default), ProxyAgent connections where both the Proxy and Endpoint are unsecured will issue all requests to the Proxy, and prefix the endpoint request path with the endpoint origin address.
31
31
 
32
32
  Examples:
33
33