Compatibility flags·续6

// However, it is backed by the same underlying memory that was passed // into the read call. console.log(result.value.buffer.byteLength); // 10 }

>
> ### Brotli Content-Encoding support
>
> | **Default as of** | 2024-04-29 |
> | --- | --- |
> | **Flag to enable** | `brotli_content_encoding` |
> | **Flag to disable** | `no_brotli_content_encoding` |
>
> When the `brotli_content_encoding` compatibility flag is enabled, Workers supports the `br` content encoding and can request and respond with data encoded using the [Brotli ↗︎](https://developer.mozilla.org/en-US/docs/Glossary/Brotli_compression) compression algorithm. This reduces the amount of data that needs to be fetched and can be used to pass through the original compressed data to the client. See the Fetch API [documentation](https://developers.cloudflare.com/workers/runtime-apis/fetch/#how-the-accept-encoding-header-is-handled) for details.
>
> ### Durable Object stubs and Service Bindings support RPC
>
> | **Default as of** | 2024-04-03 |
> | --- | --- |
> | **Flag to enable** | `rpc` |
> | **Flag to disable** | `no_rpc` |
>
> With this flag on, [Durable Object](https://developers.cloudflare.com/durable-objects/) stubs and [Service Bindings](https://developers.cloudflare.com/workers/runtime-apis/bindings/service-bindings/) support [RPC](https://developers.cloudflare.com/workers/runtime-apis/rpc/). This means that these objects now appear as if they define every possible method name. Calling any method name sends an RPC to the remote Durable Object or Worker service.
>
> For most applications, this change will have no impact unless you use it. However, it is possible some existing code will be impacted if it explicitly checks for the existence of method names that were previously not defined on these types. For example, we have seen code in the wild which iterates over [bindings](https://developers.cloudflare.com/workers/runtime-apis/bindings/) and tries to auto-detect their types based on what methods they implement. Such code will now see service bindings as implementing every method, so may misinterpret service bindings as being some other type. In the cases we have seen, the impact was benign (nothing actually broke), but out of caution we are guarding this change behind a flag.
>
> ### Handling custom thenables
>
> | **Default as of** | 2024-04-01 |
> | --- | --- |
> | **Flag to enable** | `unwrap_custom_thenables` |
> | **Flag to disable** | `no_unwrap_custom_thenables` |
>
> With the `unwrap_custom_thenables` flag set, various Workers APIs that accept promises will also correctly handle custom thenables (objects with a `then` method) that are not native promises, but are intended to be treated as such). For example, the `waitUntil` method of the `ExecutionContext` object will correctly handle custom thenables, allowing them to be used in place of native promises.
>
```js
async fetch(req, env, ctx) {
  ctx.waitUntil({ then(res) {
    // Resolve the thenable after 1 second
    setTimeout(res, 1000);
  } });
  // ...
}

Fetchers no longer have get/put/delete helper methods

Default as of 2024-03-26
Flag to enable fetcher_no_get_put_delete
Flag to disable fetcher_has_get_put_delete

Durable Object stubs and Service Bindings both implement a fetch() method which behaves similarly to the global fetch() method, but requests are instead sent to the destination represented by the object, rather than being routed based on the URL.

Historically, API objects that had such a fetch() method also had methods get(), put(), and delete(). These methods were thin wrappers around fetch() which would perform the corresponding HTTP method and automatically handle writing/reading the request/response bodies as needed.

These methods were a very early idea from many years ago, but were never actually documented, and therefore rarely (if ever) used. Enabling the fetcher_no_get_put_delete, or setting a compatibility date on or after 2024-03-26 disables these methods for your Worker.

This change paves a future path for you to be able to define your own custom methods using these names. Without this change, you would be unable to define your own get, put, and delete methods, since they would conflict with these built-in helper methods.

Queues send messages in JSON format

Default as of 2024-03-18
Flag to enable queues_json_messages
Flag to disable no_queues_json_messages

With the queues_json_messages flag set, Queue bindings will serialize values passed to send() or sendBatch() into JSON format by default (when no specific contentType is provided).

Suppress global importScripts()

Default as of 2024-03-04
Flag to enable no_global_importscripts
Flag to disable global_importscripts

Suppresses the global importScripts() function. This method was included in the Workers global scope but was marked explicitly as non-implemented. However, the presence of the function could cause issues with some libraries. This compatibility flag removes the function from the global scope.

Node.js AsyncLocalStorage

Flag to enable nodejs_als
Flag to disable no_nodejs_als

Enables the availability of the Node.js AsyncLocalStorage ↗︎ API in Workers.

Python Workers

Flag to enable python_workers

This flag enables first class support for Python. Python Workers implement the majority of Python's standard library, support all bindings, environment variable, and secrets, and integration with JavaScript objects and functions via a foreign function interface.

WebCrypto preserve publicExponent field

Default as of 2023-12-01
Flag to enable crypto_preserve_public_exponent
Flag to disable no_crypto_preserve_public_exponent

In the WebCrypto API, the publicExponent field of the algorithm of RSA keys would previously be an ArrayBuffer. Using this flag, publicExponent is a Uint8Array as mandated by the specification.

Vectorize query with metadata optionally returned

Default as of 2023-11-08
Flag to enable vectorize_query_metadata_optional
Flag to disable vectorize_query_original

A set value on vectorize_query_metadata_optional indicates that the Vectorize query operation should accept newer arguments with returnValues and returnMetadata specified discretely over the older argument returnVectors. This also changes the return format. If the vector values have been indicated for return, the return value is now a flattened vector object with score attached where it previously contained a nested vector object.

WebSocket Compression

Default as of 2023-08-15
Flag to enable web_socket_compression
Flag to disable no_web_socket_compression

The Workers runtime did not support WebSocket compression when the initial WebSocket implementation was released. Historically, the runtime has stripped or ignored the Sec-WebSocket-Extensions header -- but is now capable of fully complying with the WebSocket Compression RFC. Since many clients are likely sending Sec-WebSocket-Extensions: permessage-deflate to their Workers today (new WebSocket(url) automatically sets this in browsers), we have decided to maintain prior behavior if this flag is absent.

If the flag is present, the Workers runtime is capable of using WebSocket Compression on both inbound and outbound WebSocket connections.

Like browsers, calling new WebSocket(url) in a Worker will automatically set the Sec-WebSocket-Extensions: permessage-deflate header. If you are using the non-standard fetch() API to obtain a WebSocket, you can include the Sec-WebSocket-Extensions header with value permessage-deflate and include any of the compression parameters defined in RFC-7692 ↗︎.

Strict crypto error checking

Default as of 2023-08-01
Flag to enable strict_crypto_checks
Flag to disable no_strict_crypto_checks

Perform additional error checking in the Web Crypto API to conform with the specification and reject possibly unsafe key parameters:

  • For RSA key generation, key sizes are required to be multiples of 128 bits as boringssl may otherwise truncate the key.
  • The size of imported RSA keys must be at least 256 bits and at most 16384 bits, as with newly generated keys.
  • The public exponent for imported RSA keys is restricted to the commonly used values [3, 17, 37, 65537].
  • In conformance with the specification, an error will be thrown when trying to import a public ECDH key with non-empty usages.

Strict compression error checking

Default as of 2023-08-01
Flag to enable strict_compression_checks
Flag to disable no_strict_compression_checks

Perform additional error checking in the Compression Streams API and throw an error if a DecompressionStream has trailing data or gets closed before the full compressed data has been provided.

Override cache rules cache settings in request.cf object for Fetch API

Default as of 2025-04-02
Flag to enable request_cf_overrides_cache_rules
Flag to disable no_request_cf_overrides_cache_rules

This flag changes the behavior of cache when requesting assets via the Fetch API. Cache settings specified in the request.cf object, such as cacheEverything and cacheTtl, are now given precedence over any Cache Rules set.

Bot Management data

Default as of 2023-08-01
Flag to enable no_cf_botmanagement_default
Flag to disable cf_botmanagement_default

This flag streamlines Workers requests by reducing unnecessary properties in the request.cf object.

With the flag enabled - either by default after 2023-08-01 or by setting the no_cf_botmanagement_default flag - Cloudflare will only include the Bot Management object in a Worker's request.cf if the account has access to Bot Management.

With the flag disabled, Cloudflare will include a default Bot Management object, regardless of whether the account is entitled to Bot Management.

URLSearchParams delete() and has() value argument

Default as of 2023-07-01
Flag to enable urlsearchparams_delete_has_value_arg
Flag to disable no_urlsearchparams_delete_has_value_arg

The WHATWG introduced additional optional arguments to the URLSearchParams object delete() ↗︎ and has() ↗︎ methods that allow for more precise control over the removal of query parameters. Because the arguments are optional and change the behavior of the methods when present there is a risk of breaking existing code. If your compatibility date is set to July 1, 2023 or after, this compatibility flag will be enabled by default.

For an example of how this change could break existing code, consider code that uses the Array forEach() method to iterate through a number of parameters to delete: 

const usp = new URLSearchParams();
// ...
['abc', 'xyz'].forEach(usp.delete.bind(usp));

The forEach() automatically passes multiple parameters to the function that is passed in. Prior to the addition of the new standard parameters, these extra arguments would have been ignored.

Now, however, the additional arguments have meaning and change the behavior of the function. With this flag, the example above would need to be changed to: 

const usp = new URLSearchParams();
// ...
['abc', 'xyz'].forEach((key) => usp.delete(key));

Use a spec compliant URL implementation in redirects

Default as of 2023-03-14
Flag to enable response_redirect_url_standard
Flag to disable response_redirect_url_original

Change the URL implementation used in Response.redirect() to be spec-compliant (WHATWG URL Standard).

Dynamic Dispatch Exception Propagation

Default as of 2023-03-01
Flag to enable dynamic_dispatch_tunnel_exceptions
Flag to disable dynamic_dispatch_treat_exceptions_as_500

Previously, when using Workers for Platforms' dynamic dispatch API to send an HTTP request to a user Worker, if the user Worker threw an exception, the dynamic dispatch Worker would receive an HTTP 500 error with no body. When the dynamic_dispatch_tunnel_exceptions compatibility flag is enabled, the exception will instead propagate back to the dynamic dispatch Worker. The fetch() call in the dynamic dispatch Worker will throw the same exception. This matches the similar behavior of service bindings and Durable Objects.

Headers supports getSetCookie()

Default as of 2023-03-01
Flag to enable http_headers_getsetcookie
Flag to disable no_http_headers_getsetcookie

Adds the getSetCookie() ↗︎ method to the Headers ↗︎ API in Workers. 

const response = await fetch("https://example.com");
let cookieValues = response.headers.getSetCookie();

Node.js compatibility

Default as of 2026-08-04
Flag to enable nodejs_compat
Flag to disable no_nodejs_compat

Enables Node.js APIs in the Workers Runtime. For compatibility dates of 2026-08-04 or later, Workers enables both nodejs_compat and nodejs_compat_v2 by default.

Note that some Node.js APIs are only enabled when your Worker's compatibility date is on or after the following dates:

Node.js API Enabled with nodejs_compat on or after
Disable Top-level Await in require() 2024-12-02
process.env 2025-04-01
node:http, node:https 2025-08-15
http.server 2025-09-01

Some Node.js modules are available in Workers only as non-functional stubs. These modules can be imported or required, but do not provide working implementations of the corresponding Node.js APIs. Stubs exist for compatibility with packages that check whether a module exists, and should not be used directly in application code.