Request & RequestInit
The Request class represents a complete configuration of an HTTP request.
It can be passed directly to the fetch() method or used to clone, modify, or retry an existing request.
In Scripting, the Request API behaves similarly to the browser’s Fetch API but adds native extensions, including:
- Binary
Datatype support for request bodies - Custom redirect handling
- Request timeout and cancellation
- Optional allowance for insecure (HTTP) requests
- Debug labels for internal logging
Definition
Constructor
new Request(input: string | Request, init?: RequestInit)
Creates a new Request instance from either a URL string or an existing Request object.
Parameters
| Parameter | Type | Description |
| --------- | ------------- | -------------------------------------------------------------------- | ------------------------------------------------ |
| input | string | Request | The target URL, or an existing request to clone. |
| init | RequestInit | Optional configuration object defining request settings (see below). |
Properties
Methods
clone(): Request
Creates and returns a copy of the current request. The cloned object can be safely modified (e.g., updating headers or timeout) without affecting the original request.
Example
Examples
Example 1 — Creating a Simple Request
Example 2 — POST Request with a Body
Example 3 — Cloning and Modifying a Request
RequestInit Interface
The RequestInit interface defines configuration options for HTTP requests.
It is used as the second argument to fetch() or the optional configuration object when creating a new Request.
Scripting extends this interface with additional native fields.
Definition
Field Descriptions
Relationship with fetch()
RequestInit is typically passed as the second parameter to fetch() to configure a network request.
Relationships with Other Classes
Examples
Example 1 — Custom Redirect Handling
Example 2 — Allowing Insecure Requests
Example 3 — Using a Debug Label
RedirectRequest Interface
When a request encounters an HTTP redirect, and a handleRedirect callback is defined in the Request or RequestInit object, the system will invoke that callback before following the redirect.
The callback receives a RedirectRequest object, which describes the full details of the redirect request.
You can inspect or modify this object to control whether and how the redirect should proceed.
Interface Definition
Field Descriptions
Use Cases
The handleRedirect callback allows you to:
- Inspect and validate redirect destinations for security or logic reasons.
- Modify redirect requests (add headers, update method, or include authorization tokens).
- Block unwanted or unsafe redirects.
When the callback returns:
- A modified
RedirectRequest→ The redirect proceeds using your modified configuration. null→ The redirect is canceled, and thefetch()call resolves with the current response.
Example: Intercepting and Controlling Redirects
Example: Modifying Redirect Method and Body
Notes
- If
handleRedirectis not defined, all redirects are automatically followed by default. - Returning
nullfrom the callback prevents further redirection. - Cookies are not automatically forwarded; you can manually inspect and decide whether to reuse cookies from
redirect.cookies. - Any modifications made to the
RedirectRequest(such as headers or method) will be applied before the next request is executed.
Summary
Request and RequestInit form the foundation of Scripting’s networking system:
Requestencapsulates a complete HTTP request and can be reused or cloned.RequestInitdefines configuration options for flexible initialization.- Together, they integrate tightly with
fetch(),Response,Headers,Data, andFormData.
