Request

Last updated Oct 18, 2026 The Request ↗︎ interface represents an HTTP request and is part of the Fetch API.

Background

The most common way you will encounter a Request object is as a property of an incoming request:

export default {
    async fetch(request, env, ctx) {
        return new Response('Hello World!');
    },
};

You may also want to construct a Request yourself when you need to modify a request object, because the incoming request parameter that you receive from the fetch() handler is immutable.

export default {
    async fetch(request, env, ctx) {
        const url = "https://example.com";
        const modifiedRequest = new Request(url, request);
        // ...
    },
};

The fetch() handler invokes the Request constructor. The RequestInit and RequestInitCfProperties types defined below also describe the valid parameters that can be passed to the fetch() handler.


Constructor

let request = new Request(input, options)

Parameters

  • input string | Request
  • Either a string that contains a URL, or an existing Request object.
  • options options optional
  • Optional options object that contains settings to apply to the Request.

options

An object containing properties that you want to apply to the request.

  • cache undefined | 'no-store' | 'no-cache' optional
  • Standard HTTP cache header. Only cache: 'no-store' and cache: 'no-cache' are supported. Any other cache header will result in a TypeError with the message Unsupported cache mode: <attempted-cache-mode>.
  • cf RequestInitCfProperties optional
  • Cloudflare-specific properties that can be set on the Request that control how Cloudflare’s global network handles the request.
  • method string optional
  • The HTTP request method. The default is GET. In Workers, all HTTP request methods ↗︎ are supported, except for CONNECT ↗︎.
  • headers Headers optional
  • A Headers object ↗︎.
  • body string | ReadableStream | FormData | URLSearchParams optional
  • The request body, if any.
  • Note that a request using the GET or HEAD method cannot have a body.
  • redirect string optional
  • The redirect mode to use: follow or manual. The default for a new Request object is follow. Note, however, that the incoming Request property of a FetchEvent will have redirect mode manual. Workers does not implement the error mode from the Fetch standard: passing redirect: "error" throws a TypeError as soon as the Request is constructed (including inside fetch(url, init)), before any request is sent. Use manual and check the status code of the returned response instead.
  • signal AbortSignal optional
  • If provided, the request can be canceled by triggering an abort on the corresponding AbortController.

The cf property (RequestInitCfProperties)

An object containing Cloudflare-specific properties that can be set on the Request object. For example:

// Disable ScrapeShield for this request.
fetch(event.request, { cf: { scrapeShield: false } })

Invalid or incorrectly-named keys in the cf object will be silently ignored. Consider using TypeScript and generating types by running wrangler types to ensure proper use of the cf object.

  • apps boolean optional
  • Whether Cloudflare Apps ↗︎ should be enabled for this request. Defaults to true.
  • cacheEverything boolean optional
  • Treats all content as static and caches all file types beyond the Cloudflare default cached content. Respects cache headers from the origin web server. This is equivalent to setting the Page Rule Cache Level (to Cache Everything). Defaults to false. This option applies to GET and HEAD request methods only.
  • cacheKey string optional
  • A request’s cache key is what determines if two requests are the same for caching purposes. If a request has the same cache key as some previous request, then Cloudflare can serve the same cached response for both.
  • cacheTags Array\<string> optional
  • This option appends additional Cache-Tag headers to the response from the origin server. This allows for purges of cached content based on tags provided by the Worker, without modifications to the origin server. This is performed using the Purge by Tag feature.
  • cacheTtl number optional
  • This option forces Cloudflare to cache the response for this request, regardless of what headers are seen on the response. This is equivalent to setting two Page Rules: Edge Cache TTL and Cache Level (to Cache Everything). The value must be zero or a positive number. A value of 0 indicates that the cache asset expires immediately. This option applies to GET and HEAD request methods only.
  • cacheTtlByStatus { [key: string]: number } optional
  • This option is a version of the cacheTtl feature which chooses a TTL based on the response’s status code. If the response to this request has a status code that matches, Cloudflare will cache for the instructed time and override cache instructives sent by the origin. For example: { "200-299": 86400, "404": 1, "500-599": 0 }. The value can be any integer, including zero and negative integers. A value of 0 indicates that the cache asset expires immediately. Any negative value instructs Cloudflare not to cache at all. This option applies to GET and HEAD request methods only.
  • vary RequestInitCfPropertiesVary optional
  • Controls how Cloudflare caches origin responses with a Vary header for a single fetch() request. If both cf.vary and Cache Rules Vary apply, cf.vary takes precedence for this subrequest.
  • image Object | null optional
  • Enables Image Resizing for this request. The possible values are described in Transform images via Workers documentation.
  • polish string optional
  • Sets Polish ↗︎ mode. The possible values are lossy, lossless or off.
  • resolveOverride string optional
  • Directs the request to an alternate origin server by overriding the DNS lookup. The value of resolveOverride specifies an alternate hostname which will be used when determining the origin IP address, instead of using the hostname specified in the URL. The Host header of the request will still match what is in the URL. Thus, resolveOverride allows a request to be sent to a different server than the URL / Host header specifies. However, resolveOverride will only take effect if both the URL host and the host specified by resolveOverride are within your zone. If either specifies a host from a different zone / domain, then the option will be ignored for security reasons. If you need to direct a request to a host outside your zone (while keeping the Host header pointing within your zone), first create a CNAME record within your zone pointing to the outside host, and then set resolveOverride to point at the CNAME record. Note that, for security reasons, it is not possible to set the Host header to specify a host outside of your zone unless the request is actually being sent to that host.
  • scrapeShield boolean optional
  • Whether ScrapeShield ↗︎ should be enabled for this request, if otherwise configured for this zone. Defaults to true.
  • webp boolean optional
  • Enables or disables WebP ↗︎ image format in Polish.

The cf.vary property

The cf.vary object controls how Cloudflare handles request headers named by the origin Vary response header for a single fetch() request. It uses the same default and headers shape as Cache Rules Vary, and the same actions and normalization behavior as Vary.

If you omit cf.vary, Cloudflare uses other Vary behavior for the zone, including Cache Rules Vary if configured.

The origin response must include a Vary header for this setting to affect the cache key. A response containing Vary: * always bypasses cache.

The cf.vary object supports these keys:

Key Required Description
default Yes Configuration for any header name in the origin Vary response that is not included in headers.
headers No A map of lowercase request header names to configuration objects.

If the vary object is present, default is required. An empty vary object is invalid. Invalid cf.vary configurations are ignored for that request.

Each header configuration object, and the default object, must include an action key set to one of normalize, passthrough, or bypass. For guidance, refer to Actions.

Additional parameters can be specified for certain header names:

Header Additional key Description
accept media_types MIME types to keep when normalizing the Accept header. Maximum 10 items and 255 characters per item.
accept-language languages Languages to keep when normalizing the Accept-Language header. Maximum 20 items and 64 characters per item.

The default object and headers entries other than accept and accept-language support only action.

For most deployments, set default.action to bypass, add headers entries for expected origin Vary headers, and use normalize for accept and accept-language unless your origin requires raw header values.

The following limits and validation rules apply:

  • Header names in headers must be lowercase.
  • Header names can contain lowercase letters, numbers, underscores, and hyphens.
  • Header names cannot exceed 128 characters.
  • Header names beginning with cf- or cf_ are not allowed.
  • Certain hop-by-hop, cache-control, or proxy-control headers are not allowed. Examples include connection, content-length, cache-control, host, range, origin, and x-forwarded-for.
  • headers can contain up to 50 entries.
  • accept.media_types can contain up to 10 entries.
  • accept-language.languages can contain up to 20 entries.
  • Values in media_types and languages must be non-empty printable ASCII strings.

The following request init fragment normalizes Accept and Accept-Language, and bypasses cache for any other header in the origin Vary response:

Request init fragmentjson

{
    "cf": {
        "vary": {
            "default": {
                "action": "bypass"
            },
            "headers": {
                "accept": {
                    "action": "normalize",
                    "media_types": ["text/html", "application/json"]
                },
                "accept-language": {
                    "action": "normalize",
                    "languages": ["en", "fr", "de"]
                }
            }
        }
    }
}

Properties

All properties of an incoming Request object (the request you receive from the fetch() handler) are read-only. To modify the properties of an incoming request, create a new Request object and pass the options to modify to its constructor.

  • body ReadableStream read-only
  • Stream of the body contents.
  • bodyUsed Boolean read-only
  • Declares whether the body has been used in a response yet.
  • cf IncomingRequestCfProperties read-only
  • An object containing properties about the incoming request provided by Cloudflare’s global network.
  • This property is read-only (unless created from an existing Request). To modify its values, pass in the new values on the cf key of the init options argument when creating a new Request object.
  • headers Headers read-only
  • A Headers object ↗︎.
  • Compared to browsers, Cloudflare Workers imposes very few restrictions on what headers you are allowed to send. For example, a browser will not allow you to set the Cookie header, since the browser is responsible for handling cookies itself. Workers, however, has no special understanding of cookies, and treats the Cookie header like any other header.

Caution

If the response is a redirect and the redirect mode is set to follow (see below), then all headers will be forwarded to the redirect destination, even if the destination is a different hostname or domain. This includes sensitive headers like Cookie, Authorization, or any application-specific headers. If this is not the behavior you want, you should set redirect mode to manual and implement your own redirect policy. Note that redirect mode defaults to manual for requests that originated from the Worker's client, so this warning only applies to fetch()es made by a Worker that are not proxying the original request. - method string read-only - Contains the request’s method, for example, GET, POST, etc. - redirect string read-only - The redirect mode to use: follow or manual. The fetch method will automatically follow redirects if the redirect mode is set to follow. If set to manual, the 3xx redirect response will be returned to the caller as-is. The error mode from the Fetch standard is not implemented in Workers, and passing it throws a TypeError when the Request is constructed. The default for a new Request object is follow. Note, however, that the incoming Request property of a FetchEvent will have redirect mode manual. - signal AbortSignal read-only - The AbortSignal corresponding to this request. If you use the enable_request_signal compatibility flag, you can attach an event listener to the signal. This allows you to perform cleanup tasks or write to logs before your Worker's invocation ends. For example, if you run the Worker below, and then abort the request from the client, a log will be written: