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 +16 -14
- package/docs/docs/api/DiagnosticsChannel.md +25 -1
- package/docs/docs/api/ProxyAgent.md +1 -1
- package/docs/docs/api/SnapshotAgent.md +616 -0
- package/index.js +2 -0
- package/lib/api/readable.js +48 -26
- package/lib/core/util.js +0 -1
- package/lib/dispatcher/proxy-agent.js +68 -73
- package/lib/handler/cache-handler.js +22 -4
- package/lib/handler/redirect-handler.js +10 -0
- package/lib/interceptor/cache.js +2 -2
- package/lib/interceptor/dump.js +2 -1
- package/lib/mock/mock-agent.js +10 -4
- package/lib/mock/snapshot-agent.js +347 -0
- package/lib/mock/snapshot-recorder.js +580 -0
- package/lib/mock/snapshot-utils.js +158 -0
- package/lib/util/cache.js +3 -3
- package/lib/web/cache/cache.js +4 -4
- package/lib/web/eventsource/eventsource.js +17 -2
- package/lib/web/fetch/body.js +0 -1
- package/lib/web/fetch/formdata-parser.js +0 -3
- package/lib/web/fetch/formdata.js +1 -5
- package/lib/web/fetch/response.js +8 -4
- package/lib/web/webidl/index.js +1 -1
- package/lib/web/websocket/stream/websocketstream.js +2 -2
- package/lib/web/websocket/websocket.js +11 -4
- package/package.json +5 -5
- package/types/agent.d.ts +0 -4
- package/types/client.d.ts +0 -2
- package/types/dispatcher.d.ts +0 -6
- package/types/eventsource.d.ts +6 -1
- package/types/h2c-client.d.ts +0 -2
- package/types/index.d.ts +6 -1
- package/types/mock-interceptor.d.ts +0 -1
- package/types/snapshot-agent.d.ts +107 -0
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.
|
|
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
|
-
|
|
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
|
|
624
|
-
|
|
625
|
-
| 5.x
|
|
626
|
-
| 6.x
|
|
627
|
-
| 7.x
|
|
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(({
|
|
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) -
|
|
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
|
|