GeezerVison

`npm run test:wpt` and `node test/web-platform-tests/wpt-runner.mjs setup` will initialize the WPT submodule automatically when it is missing.

If you want to prepare the checkout explicitly, run:

git submodule update --init --recursive

const data = await body.json();

When you send a `FormData` body, keep `fetch` and `FormData` from the same

implementation.

Use one of these patterns:

const body = new FormData()

body.set('name', 'some')

await fetch('https://example.com', {

method: 'POST',

body

})

import { fetch, FormData } from 'undici'

const body = new FormData()

body.set('name', 'some')

await fetch('https://example.com', {

method: 'POST',

body

})

If you want the installed `undici` package to provide the globals, call

`install()` first:

import { install } from 'undici'

install()

const body = new FormData()

body.set('name', 'some')

await fetch('https://example.com', {

method: 'POST',

body

})

`install()` replaces the global `fetch`, `Headers`, `Response`, `Request`, and

`FormData` implementations with undici's versions, so they all match.

Avoid mixing a global `FormData` with `undici.fetch()`, or `undici.FormData`

with the built-in global `fetch()`.

You can check which version of undici is bundled with your Node.js version:

- `CloseEvent`, `ErrorEvent`, `MessageEvent` - WebSocket events

- `EventSource` - Server-sent events client

When you call `install()`, these globals come from the same undici

implementation. For example, global `fetch` and global `FormData` will both be

undici's versions, which is the recommended setup if you want to use undici

through globals.

This is useful for:

- Polyfilling environments that don't have fetch

- Ensuring consistent fetch behavior across different Node.js versions

console.log(websocket) // the WebSocket instance

// Handshake response details

console.log(handshakeResponse.status) // 101 for successful WebSocket upgrade

console.log(handshakeResponse.statusText) // 'Switching Protocols'

console.log(handshakeResponse.status) // 101 for HTTP/1.1, 200 for HTTP/2 extended CONNECT

console.log(handshakeResponse.statusText) // 'Switching Protocols' for HTTP/1.1, commonly 'OK' for HTTP/2 in Node.js

console.log(handshakeResponse.headers) // Object containing response headers

})

The `handshakeResponse` object contains the HTTP response that upgraded the connection to WebSocket:

The `handshakeResponse` object contains the HTTP response that established the WebSocket connection:

- `status` (number): The HTTP status code (101 for successful WebSocket upgrade)

- `statusText` (string): The HTTP status message ('Switching Protocols' for successful upgrade)

- `status` (number): The HTTP status code (`101` for HTTP/1.1 upgrade, `200` for HTTP/2 extended CONNECT)

- `statusText` (string): The HTTP status message (`'Switching Protocols'` for HTTP/1.1, commonly `'OK'` for HTTP/2 in Node.js)

- `headers` (object): The HTTP response headers from the server, including:

- `sec-websocket-accept` and other WebSocket-related headers

- `upgrade: 'websocket'`

- `connection: 'upgrade'`

- `sec-websocket-accept` and other WebSocket-related headers

The `upgrade` and `connection` headers are only present for HTTP/1.1 handshakes.

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.

For easy use with [stream.pipeline](https://nodejs.org/api/stream.html#stream_stream_pipeline_source_transforms_destination_callback). The `handler` argument should return a `Readable` from which the result will be read. Usually it should just return the `body` argument unless some kind of transformation needs to be performed based on e.g. `headers` or `statusCode`. The `handler` should validate the response and save any required state. If there is an error, it should be thrown. The function returns a `Duplex` which writes to the request and reads from the response.

For easy use with [stream.pipeline](https://nodejs.org/api/stream.html#streampipelinesource-transforms-destination-options). The `handler` argument should return a `Readable` from which the result will be read. Usually it should just return the `body` argument unless some kind of transformation needs to be performed based on e.g. `headers` or `statusCode`. The `handler` should validate the response and save any required state. If there is an error, it should be thrown. The function returns a `Duplex` which writes to the request and reads from the response.

Arguments:

const { redirect } = interceptors;

const client = new Client("http://service.example").compose(

redirect({ maxRedirections: 3, throwOnMaxRedirects: true })

redirect({ maxRedirections: 3, throwOnMaxRedirect: true })

);

client.request({ path: "/" })

- `dualStack` - Whether to resolve both IPv4 and IPv6 addresses. Default: `true`.

- It will also attempt a happy-eyeballs-like approach to connect to the available addresses in case of a connection failure.

- `affinity` - Whether to use IPv4 or IPv6 addresses. Default: `4`.

- It can be either `'4` or `6`.

- It can be either `4` or `6`.

- It will only take effect if `dualStack` is `false`.

- `lookup: (hostname: string, options: LookupOptions, callback: (err: NodeJS.ErrnoException | null, addresses: DNSInterceptorRecord[]) => void) => void` - Custom lookup function. Default: `dns.lookup`.

- For more info see [dns.lookup](https://nodejs.org/api/dns.html#dns_dns_lookup_hostname_options_callback).

- For more info see [dns.lookup](https://nodejs.org/api/dns.html#dnslookuphostname-options-callback).

- `pick: (origin: URL, records: DNSInterceptorRecords, affinity: 4 | 6) => DNSInterceptorRecord` - Custom pick function. Default: `RoundRobin`.

- The function should return a single record from the records array.

- By default a simplified version of Round Robin is used.

If any parameters are passed to the FormData constructor other than `undefined`, an error will be thrown. Other parameters are ignored.

When you use `FormData` as a request body, keep `fetch` and `FormData` from the

same implementation. Use the built-in global `FormData` with the built-in

global `fetch()`, and use `undici`'s `FormData` with `undici.fetch()`.

If you want the installed `undici` package to provide the globals, call

[`install()`](/docs/api/GlobalInstallation.md) so `fetch`, `Headers`,

`Response`, `Request`, and `FormData` are installed together as a matching set.

This API is implemented as per the standard, you can find documentation on [MDN](https://developer.mozilla.org/en-US/docs/Web/API/Response)

| `MessageEvent` | WebSocket message event |

| `EventSource` | Server-sent events client |

If you send a `FormData` body, use matching implementations for `fetch` and

`FormData`.

These two patterns are safe:

const body = new FormData()

await fetch('https://example.com', {

method: 'POST',

body

})

import { install } from 'undici'

install()

const body = new FormData()

await fetch('https://example.com', {

method: 'POST',

body

})

After `install()`, `fetch`, `Headers`, `Response`, `Request`, and `FormData`

all come from the installed `undici` package, so they work as a matching set.

If you do not want to install globals, import both from `undici` instead:

import { fetch, FormData } from 'undici'

const body = new FormData()

await fetch('https://example.com', {

method: 'POST',

body

})

Avoid mixing a global `FormData` with `undici.fetch()`, or `undici.FormData`

with the built-in global `fetch()`. Keeping them paired avoids surprising

multipart behavior across Node.js and undici versions.

Global installation is useful for:

A class that handles redirection logic for HTTP requests.

Arguments:

- **dispatch** `function` - The dispatch function to be called after every retry.

- **maxRedirections** `number` - Maximum number of redirections allowed.

- **opts** `object` - Options for handling redirection.

- **handler** `object` - An object containing handlers for different stages of the request lifecycle.

- **redirectionLimitReached** `boolean` (default: `false`) - A flag that the implementer can provide to enable or disable the feature. If set to `false`, it indicates that the caller doesn't want to use the feature and prefers the old behavior.

Returns: `RedirectHandler`

- **maxRedirections** `number` (required) - Maximum number of redirections allowed.

- **opts** `object` (required) - Options for handling redirection.

- **handler** `object` (required) - Handlers for different stages of the request lifecycle.

- **redirectionLimitReached** `boolean` (default: `false`) - A flag that the implementer can provide to enable or disable the feature. If set to `false`, it indicates that the caller doesn't want to use the feature and prefers the old behavior.

- **maxRedirections** `number` - Maximum number of redirections allowed.

- **handler** `object` - Handlers for different stages of the request lifecycle.

- **history** `Array` - An array representing the history of URLs during redirection.

- **redirectionLimitReached** `boolean` - Indicates whether the redirection limit has been reached.

additional APIs, and potentially a newer release than what your Node.js version

bundles.

When you send a `FormData` body, keep `fetch` and `FormData` together from the

same implementation.

Use one of these patterns:

const body = new FormData()

body.set('name', 'some')

body.set('someOtherProperty', '8000')

await fetch('https://example.com', {

method: 'POST',

body

})

import { fetch, FormData } from 'undici'

const body = new FormData()

body.set('name', 'some')

body.set('someOtherProperty', '8000')

await fetch('https://example.com', {

method: 'POST',

body

})

If you want the installed `undici` package to provide the globals, call

[`install()`](/docs/api/GlobalInstallation.md):

import { install } from 'undici'

install()

const body = new FormData()

body.set('name', 'some')

body.set('someOtherProperty', '8000')

await fetch('https://example.com', {

method: 'POST',

body

})

`install()` replaces the global `fetch`, `Headers`, `Response`, `Request`, and

`FormData` implementations with undici's versions, and also installs undici's

`WebSocket`, `CloseEvent`, `ErrorEvent`, `MessageEvent`, and `EventSource`

globals.

Avoid mixing implementations in the same request, for example:

import { fetch } from 'undici'

const body = new FormData()

await fetch('https://example.com', {

method: 'POST',

body

})

import { FormData } from 'undici'

const body = new FormData()

await fetch('https://example.com', {

method: 'POST',

body

})

Those combinations may behave differently across Node.js and undici versions.

Using matching pairs keeps multipart handling predictable.

If all of the following are true, you can rely on the built-in globals and skip

`process.versions.undici`.

Installing undici from npm does not replace the built-in globals. If you want

your installed version to override the global `fetch`, use

[`setGlobalDispatcher`](/docs/api/GlobalInstallation.md) or import `fetch`

your installed version to replace the global `fetch` and related classes, use

[`install()`](/docs/api/GlobalInstallation.md). Otherwise, import `fetch`

directly from `'undici'`:

import { fetch } from 'undici'; // uses your installed version, not the built-in

import { fetch } from 'undici' // uses your installed version, not the built-in