workerd

Default as of

2023-11-08

Enable flag

vectorize_query_metadata_optional

Disable flag

vectorize_query_original

Publicly Documented

Yes

Usable

Yes

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.

Default as of

2023-12-01

Enable flag

crypto_preserve_public_exponent

Disable flag

no_crypto_preserve_public_exponent

Publicly Documented

Yes

Usable

Yes

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.

Enable flag

webgpu

Experimental

Yes

Publicly Documented

No

Usable

No

Enable flag

rtti_api

Experimental

Yes

Publicly Documented

No

Usable

No

Default as of

2023-08-01

Enable flag

strict_crypto_checks

Disable flag

no_strict_crypto_checks

Publicly Documented

Yes

Usable

Yes

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.

Enable flag

brotli_content_encoding

Disable flag

no_brotli_content_encoding

Publicly Documented

No

Usable

Yes

Default as of

2023-08-01

Enable flag

strict_compression_checks

Disable flag

no_strict_compression_checks

Publicly Documented

Yes

Usable

Yes

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.

Default as of

2023-07-01

Enable flag

urlsearchparams_delete_has_value_arg

Disable flag

no_urlsearchparams_delete_has_value_arg

Publicly Documented

No

Usable

Yes

Default as of

2023-08-01

Enable flag

no_cf_botmanagement_default

Disable flag

cf_botmanagement_default

Publicly Documented

No

Usable

Yes

Enable flag

service_binding_extra_handlers

Experimental

Yes

Publicly Documented

No

Usable

No

Default as of

2023-03-01

Enable flag

dynamic_dispatch_tunnel_exceptions

Disable flag

dynamic_dispatch_treat_exceptions_as_500

Publicly Documented

Yes

Usable

Yes

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.

Default as of

2023-03-01

Enable flag

http_headers_getsetcookie

Disable flag

no_http_headers_getsetcookie

Publicly Documented

Yes

Usable

Yes

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

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

Enable flag

durable_object_get_existing

Experimental

Yes

Publicly Documented

No

Usable

No

Enable flag

experimental

Experimental

Yes

Publicly Documented

No

Usable

No

Default as of

2023-03-14

Enable flag

response_redirect_url_standard

Disable flag

response_redirect_url_original

Publicly Documented

Yes

Usable

Yes

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

Enable flag

tcp_sockets_support

Publicly Documented

No

Usable

Yes

Enable flag

nodejs_compat

Disable flag

no_nodejs_compat

Publicly Documented

No

Usable

Yes

Default as of

2023-08-15

Enable flag

web_socket_compression

Disable flag

no_web_socket_compression

Publicly Documented

Yes

Usable

Yes

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.

Enable flag

durable_object_rename

Experimental

Yes

Publicly Documented

No

Usable

No

Default as of

2022-10-31

Enable flag

export_commonjs_default

Disable flag

export_commonjs_namespace

Publicly Documented

Yes

Usable

Yes

CommonJS modules were previously exporting a module namespace (an object like { default: module.exports }) rather than exporting only the module.exports. When this flag is enabled, the export is fixed.

Default as of

2022-08-04

Enable flag

r2_list_honor_include

Publicly Documented

Yes

Usable

Yes

With the r2_list_honor_include flag set, the include argument to R2 list options is honored. With an older compatibility date and without this flag, the include argument behaves implicitly as include: ["httpMetadata", "customMetadata"].

Default as of

2022-11-30

Enable flag

transformstream_enable_standard_constructor

Disable flag

transformstream_disable_standard_constructor

Publicly Documented

Yes

Usable

Yes

Previously, the new TransformStream() constructor was not compliant with the Streams API standard. Use the transformstream_enable_standard_constructor to opt-in to the backwards-incompatible change to make the constructor compliant. Must be used in combination with the streams_enable_constructors flag.

Default as of

2022-06-01

Enable flag

dont_substitute_null_on_type_error

Disable flag

substitute_null_on_type_error

Publicly Documented

Yes

Usable

Yes

There was a bug in the runtime that meant that when being passed into built-in APIs, invalid values were sometimes mistakenly coalesced with null. Instead, a TypeError should have been thrown. The dont_substitute_null_on_type_error fixes this behavior so that an error is correctly thrown in these circumstances.

Enable flag

durable_object_alarms

Publicly Documented

No

Usable

Yes

Enable flag

r2_public_beta_bindings

Disable flag

r2_internal_beta_bindings

Publicly Documented

No

Usable

Yes

Default as of

2022-10-31

Enable flag

capture_async_api_throws

Disable flag

do_not_capture_async_api_throws

Publicly Documented

Yes

Usable

Yes

The capture_async_api_throws compatibility flag will ensure that, in conformity with the standards API, async functions will only ever reject if they throw an error. The inverse do_not_capture_async_api_throws flag means that async functions which contain an error may throw that error synchronously rather than rejecting.

Default as of

2022-03-21

Enable flag

global_navigator

Disable flag

no_global_navigator

Publicly Documented

Yes

Usable

Yes

With the global_navigator flag set, a new global navigator property is available from within Workers. Currently, it exposes only a single navigator.userAgent property whose value is set to 'Cloudflare-Workers'. This property can be used to reliably determine whether code is running within the Workers environment.

Default as of

2022-10-31

Enable flag

url_standard

Disable flag

url_original

Publicly Documented

Yes

Usable

Yes

The original implementation of the URL API in Workers was not fully compliant with the WHATWG URL Standard, differing in several ways, including:

• The original implementation collapsed sequences of multiple slashes into a single slash:

  new URL("https://example.com/a//b").toString() === "https://example.com/a/b"

• The original implementation would throw "TypeError: Invalid URL string." if it encountered invalid percent-encoded escape sequences, like https://example.com/a%%b.

• The original implementation would percent-encode or percent-decode certain content differently:

  new URL("https://example.com/a%40b?c d%20e?f").toString() === "https://example.com/a@b?c+d+e%3Ff"

• The original implementation lacked more recently implemented URL features, like URL.canParse().

Set the compatibility date of your Worker to a date after 2022-10-31 or enable the url_standard compatibility flag to opt-in the fully spec compliant URL API implementation.

Refer to the response_redirect_url_standard compatibility flag , which affects the URL implementation used in Response.redirect().

Default as of

2022-03-08

Enable flag

no_cots_on_external_fetch

Disable flag

cots_on_external_fetch

Publicly Documented

Yes

Usable

Yes

The no_cots_on_external_fetch flag disables the use of the Custom Origin Trust Store when making external (grey-clouded) subrequests from a Cloudflare Worker.

Default as of

2022-04-05

Enable flag

minimal_subrequests

Disable flag

no_minimal_subrequests

Publicly Documented

Yes

Usable

Yes

With the minimal_subrequests flag set, fetch() subrequests sent to endpoints on the Worker's own zone (also called same-zone subrequests) have a reduced set of features applied to them. In general, these features should not have been initially applied to same-zone subrequests, and very few user-facing behavior changes are anticipated. Specifically, Workers might observe the following behavior changes with the new flag:

• Response bodies will not be opportunistically gzipped before being transmitted to the Workers runtime. If a Worker reads the response body, it will read it in plaintext, as has always been the case, so disabling this prevents unnecessary decompression. Meanwhile, if the Worker passes the response through to the client, Cloudflare's HTTP proxy will opportunistically gzip the response body on that side of the Workers runtime instead. The behavior change observable by a Worker script should be that some Content-Encoding: gzip headers will no longer appear.
• Automatic Platform Optimization may previously have been applied on both the Worker's initiating request and its subrequests in some circumstances. It will now only apply to the initiating request.
• Link prefetching will now only apply to the Worker's response, not responses to the Worker's subrequests.

Default as of

2022-01-31

Enable flag

workers_api_getters_setters_on_prototype

Disable flag

workers_api_getters_setters_on_instance

Publicly Documented

Yes

Usable

Yes

Originally, properties on Workers API objects were defined as instance properties as opposed to prototype properties. This broke subclassing at the JavaScript layer, preventing a subclass from correctly overriding the superclass getters/setters. This flag controls the breaking change made to set those getters/setters on the prototype template instead.

This changes applies to:

• AbortSignal
• AbortController
• Blob
• Body
• DigestStream
• Event
• File
• Request
• ReadableStream
• ReadableStreamDefaultReader
• ReadableStreamBYOBReader
• Response
• TextDecoder
• TextEncoder
• TransformStream
• URL
• WebSocket
• WritableStream
• WritableStreamDefaultWriter

Default as of

2022-11-30

Enable flag

streams_enable_constructors

Disable flag

streams_disable_constructors

Publicly Documented

Yes

Usable

Yes

Adds the work-in-progress new ReadableStream() and new WritableStream() constructors backed by JavaScript underlying sources and sinks.

Default as of

2021-11-10

Enable flag

streams_byob_reader_detaches_buffer

Disable flag

streams_byob_reader_does_not_detach_buffer

Publicly Documented

Yes

Usable

Yes

Originally, the Workers runtime did not detach the ArrayBuffers from user-provided TypedArrays when using the BYOB reader's read() method, as required by the Streams spec, meaning it was possible to inadvertently reuse the same buffer for multiple read() calls. This change makes Workers conform to the spec.

User code should never try to reuse an ArrayBuffer that has been passed into a BYOB reader's read() method. Instead, user code can reuse the ArrayBuffer backing the result of the read() promise, as in the example below.

// Consume and discard `readable` using a single 4KiB buffer.
let reader = readable.getReader({ mode: "byob" });
let arrayBufferView = new Uint8Array(4096);
while (true) {
  let result = await reader.read(arrayBufferView);
  if (result.done) break;
  // Optionally something with `result` here.
  // Re-use the same memory for the next `read()` by creating
  // a new Uint8Array backed by the result's ArrayBuffer.
  arrayBufferView = new Uint8Array(result.value.buffer);
}

The more recently added extension method readAtLeast() will always detach the ArrayBuffer and is unaffected by this feature flag setting.

Default as of

2021-11-10

Enable flag

durable_object_fetch_requires_full_url

Disable flag

durable_object_fetch_allows_relative_url

Publicly Documented

Yes

Usable

Yes

Originally, when making a request to a Durable Object by calling stub.fetch(url), a relative URL was accepted as an input. The URL would be interpreted relative to the dummy URL http://fake-host, and the resulting absolute URL was delivered to the destination object's fetch() handler. This was a mistake — full URLs were meant to be required. This flag makes full URLs required.

Enable flag

html_rewriter_treats_esi_include_as_void_tag

Experimental

Yes

Publicly Documented

Yes

Usable

Yes

The HTML5 standard defines a fixed set of elements as void elements, meaning they do not use an end tag: <area>, <base>, <br>, <col>, <command>, <embed>, <hr>, <img>, <input>, <keygen>, <link>, <meta>, <param>, <source>, <track>, and <wbr>.

HTML5 does not recognize XML self-closing tag syntax. For example, <script src="foo.js" /> does not specify a script element with no body. A </script> ending tag is still required. The /> syntax simply is not recognized by HTML5 at all and it is treated the same as >. However, many developers still like to use this syntax, as a holdover from XHTML, a standard which failed to gain traction in the early 2000's.

<esi:include> and <esi:comment> are two tags that are not part of the HTML5 standard, but are instead used as part of Edge Side Includes, a technology for server-side HTML modification. These tags are not expected to contain any body and are commonly written with XML self-closing syntax.

HTMLRewriter was designed to parse standard HTML5, not ESI. However, it would be useful to be able to implement some parts of ESI using HTMLRewriter. To that end, this compatibility flag causes HTMLRewriter to treat <esi:include> and <esi:comment> as void tags, so that they can be parsed and handled properly.

Default as of

2021-11-10

Enable flag

fetch_refuses_unknown_protocols

Disable flag

fetch_treats_unknown_protocols_as_http

Publicly Documented

Yes

Usable

Yes

Originally, if the fetch() function was passed a URL specifying any protocol other than http: or https:, it would silently treat it as if it were http:. For example, fetch() would appear to accept ftp: URLs, but it was actually making HTTP requests instead.

Note that Cloudflare Workers supports a non-standard extension to fetch() to make it support WebSockets. However, when making an HTTP request that is intended to initiate a WebSocket handshake, you should still use http: or https: as the protocol, not ws: nor wss:.

The ws: and wss: URL schemes are intended to be used together with the new WebSocket() constructor, which exclusively supports WebSocket. The extension to fetch() is designed to support HTTP and WebSocket in the same request (the response may or may not choose to initiate a WebSocket), and so all requests are considered to be HTTP.

Default as of

2021-11-03

Enable flag

formdata_parser_supports_files

Disable flag

formdata_parser_converts_files_to_strings

Publicly Documented

Yes

Usable

Yes

The FormData API is used to parse data (especially HTTP request bodies) in multipart/form-data format.

Originally, the Workers runtime's implementation of the FormData API incorrectly converted uploaded files to strings. Therefore, formData.get("filename") would return a string containing the file contents instead of a File object. This change fixes the problem, causing files to be represented using File as specified in the standard.