← Cloudflare Workers / workers / configuration

Příznaky kompatibility

Příznaky kompatibility zapínají konkrétní funkce. Hodí se, pokud chcete pomoci týmu Workers otestovat připravované změny, které ještě nejsou ve výchozím nastavení zapnuté, nebo pokud potřebujete odložit změnu, na které váš kód závisí, a přitom chcete použít ostatní změny kompatibility.

Příznaky kompatibility mívají často datum, od kterého jsou zapnuté ve výchozím nastavení, a proto při zadání compatibility_date pro váš Worker, můžete rychle povolit všechny tyto různé compatibility flags až do daného data včetně.

Můžete zadat seznam compatibility_flags, které povolují nebo zakazují konkrétní změny.

Příznaky kompatibility lze nastavit v souboru Workeru Konfigurační soubor Wrangler.

Tento příklad povoluje konkrétní příznak formdata_parser_supports_files, který je popsán níže. Od uvedeného data 2021-09-14, tento konkrétní flag ještě nebyl ve výchozím nastavení zapnutý, ale pokud ho uvedete v compatibility_flags, můžeme jej přesto povolit. compatibility_flags lze také použít k vypnutí změn, které se v minulosti staly výchozími.

{
	// Opt into backwards-incompatible changes through September 14, 2021.
	"compatibility_date": "2021-09-14",
	// Also opt into an upcoming fix to the FormData API.
	"compatibility_flags": [
		"formdata_parser_supports_files"
	]
}

compatibility_date = "2021-09-14"
compatibility_flags = [ "formdata_parser_supports_files" ]

Příznaky kompatibility lze aktualizovat v nastavení Workers na Cloudflare dashboard ↗.

Příznaky kompatibility lze nastavit při nahrávání Workeru pomocí Workers Script API nebo Workers Versions API v těle požadavku, v poli metadata .

A rostoucí podmnožina rozhraní Node.js API jsou dostupná přímo jako Runtime API, aniž byste museli do vlastního kódu přidávat polyfilly.

Pro data kompatibility 2026-08-04 nebo novější mají projekty Workers a Pages povolené oba nodejs_compat a nodejs_compat_v2 ve výchozím nastavení. Vestavěná runtime API a polyfilly jsou dostupné bez dalšího nastavení. Tyto příznaky se pro tato data kompatibility nepoužívají. Stávající projekty je při aktualizaci data kompatibility nemusí odebírat.

Pokud je vaše datum kompatibility starší než 2026-08-04, přidejte nodejs_compat příznak kompatibility do vašeho Konfigurační soubor Wrangler abyste se přihlásili:

{
	"compatibility_flags": [
		"nodejs_compat"
	]
}

compatibility_flags = [ "nodejs_compat" ]

Chcete-li vypnout Kompatibilita s Node.js zcela pro datum kompatibility 2026-08-04 nebo novější odeberte pozitivní příznaky, pokud jsou přítomné. Poté přidejte oba no_nodejs_compat a no_nodejs_compat_v2. Příklady konfigurace najdete v Příznak kompatibility s Node.js.

Pro data kompatibility 2026-08-04 nebo novější Workers povolí oba nodejs_compat a nodejs_compat_v2 ve výchozím nastavení. Tyto příznaky se pro tato data kompatibility nepoužívají, protože stejné chování zajišťuje samotné datum kompatibility. Wrangler, Miniflare, plugin Cloudflare pro Vite a plugin Workers Vitest tyto nadbytečné příznaky při spouštění runtime prostředí ignorují. Stávající projekty je při aktualizaci data kompatibility nemusí odebírat. V nových konfiguracích je vynechte.

Chcete-li úplně vypnout kompatibilitu s Node.js pro datum kompatibility 2026-08-04 nebo novější odeberte nodejs_compat a nodejs_compat_v2 pokud existuje. Poté přidejte oba následující příznaky:

{
	"compatibility_flags": [
		"no_nodejs_compat",
		"no_nodejs_compat_v2"
	]
}

compatibility_flags = [ "no_nodejs_compat", "no_nodejs_compat_v2" ]

Node.js AsyncLocalStorage API je pro Workers obzvláště užitečná funkce. Chcete-li povolit pouze AsyncLocalStorage API použijte nodejs_als příznak kompatibility.

{
	"compatibility_flags": [
		"nodejs_als"
	]
}

compatibility_flags = [ "nodejs_als" ]

Nejnovější příznaky jsou uvedeny jako první.

Když remove_nodejs_compat_eol_v24 je povoleno, rozhraní API, jejichž podpora v Node.js 24.x skončila, jsou odstraněna.

Tento příznak se automaticky povolí, když remove_nodejs_compat_eol příznak je povolen po 2028-04-30.

Když remove_nodejs_compat_eol_v22 je povoleno, rozhraní API, jejichž podpora v Node.js 22.x skončila, jsou odstraněna.

Tento příznak se automaticky povolí, když remove_nodejs_compat_eol příznak je povolen po 2027-04-30.

Je-li povoleno, předání nepodporovaných možností TLS (např. checkServerIdentity) na tls.connect() nebo new TLSSocket() vyvolá ERR_OPTION_NOT_IMPLEMENTED místo jejich tichého ignorování

Když python_process_pth_files příznak nastaven, Python Workers zpracují .pth soubory ve python_modules/ adresář při spuštění voláním site.addsitedir() ↗ na něm. To umožňuje balíčkům rozšiřovat sys.path deklarativně, například pro přidání podadresářů nebo registraci háčků pro import (import hooks). Bez tohoto příznaku .pth soubory v python_modules/ se ignorují.

Tento příznak zároveň přesouvá kontextové správce entropie nejvyšší úrovně, které vyžadují některé balíčky, mimo runtime a do workers-py ↗.

Musíte použít workers-py verze 1.1.3 nebo novější, když je tento příznak nastaven.

Když diagnostics_channel_has_subscribers_getter je povoleno, Channel.hasSubscribers a TracingChannel.hasSubscribers z node:diagnostics_channel se stávají getter vlastnostmi pouze pro čtení, které se vyhodnocují přímo na boolean, což odpovídá chování Node.js.

Dříve, hasSubscribers byla zaregistrována jako metoda, což vyžadovalo, aby uživatelé volali ch.hasSubscribers() se závorkami. Když je tento příznak zapnutý, ch.hasSubscribers vrací booleovskou hodnotu bez volání funkce, v souladu s Dokumentace Node.js ↗.

Tento příznak vyžaduje nodejs_compat aby bylo povoleno.

Je-li povoleno a pokud Workflow krok vyvolá NonRetryableError, chyba message a name vlastnosti jsou u vyvolané výjimky zachovány, místo aby byly nahrazeny obecným řetězcem ukončení.

Dříve vyhození NonRetryableError s vlastní zprávou by způsobilo, že se původní chybová zpráva ztratí a nahradí se "The execution of the Workflow instance was terminated, as a step threw an NonRetryableError and it was not handled":

import { WorkflowEntrypoint, NonRetryableError } from "cloudflare:workers";

export class MyWorkflow extends WorkflowEntrypoint {
  async run(event, step) {
    await step.do("my-step", async () => {
      throw new NonRetryableError("custom error message");
      // Without this flag: error.message === "The execution of the Workflow instance was terminated, as a step threw an NonRetryableError and it was not handled"
      // With this flag: error.message === "custom error message"
    });
  }
}

S workflows_preserve_non_retryable_error_message příznak povolen, zachová se původní zpráva a název chyby, což usnadňuje ladění a zpracování konkrétních chybových případů v kódu vašeho Workflow.

Když enhanced_error_serialization je povoleno, chyby serializované pomocí structuredClone() nebo V8 serializace podporují více typů chyb a zahrnují vlastní vlastnosti chybového objektu.

Mějte na paměti, že po povolení deserializace chyb ve výchozím nastavení nezachová původní stack trace.

Dříve pouze základní Error typy byly serializovány a vlastní vlastnosti přidané do objektů chyb se během serializace ztratily.

Když containers_pid_namespace je nastaveno, kontejnery použijí izolovaný PID namespace. ENTRYPOINT vašeho kontejneru bude mít PID 1.

Pokud není nastaveno, kontejner sdílí PID namespace s virtuálním strojem (VM), který jej obsahuje. Parametr ENTRYPOINT vašeho kontejneru bude ne mají PID 1 a další procesy běžící na VM (které nejsou součástí vašeho kontejneru) budou viditelné.

Když encoder_stream_spec_compliant_backpressure je povoleno, TextEncoderStream a TextDecoderStream použijte high water mark strany pro čtení nastavený na 0, jak je uvedeno v WHATWG Encoding Standard ↗.

Při high water mark 0 začíná čtecí strana rovnou s uplatněným backpressure, takže zápisy se správně blokují, dokud čtenář data nevyzvedne. Dříve byl high water mark ve výchozím stavu 1, což způsobovalo pull() aby se spustil při startu a vyčistil zpětný tlak (backpressure) ještě před jakýmkoli zápisem.

Když writable_stream_spec_compliant_writer je povoleno, několik WritableStream byly opraveny problémy se souladem se specifikací týkající se zámku zapisovače a chování při jeho uvolňování, aby odpovídaly WHATWG Streams Standard ↗.

Když enable_global_performance_classes je povoleno, v globálním rozsahu jsou k dispozici následující třídy: PerformanceEntry, PerformanceMark, PerformanceMeasure, PerformanceResourceTiming, PerformanceObserver, a PerformanceObserverEntryList.

Tyto třídy jsou také implicitně povoleny enable_nodejs_perf_hooks_module příznak.

Tento příznak se automaticky povolí pro Workery používající datum kompatibility 2026-03-17 nebo novější, když nodejs_compat je zapnuté.

enable_nodejs_child_process_module příznak zapíná node:child_process stub modulu ve Workers.

Tento příznak se automaticky povolí pro Workery používající datum kompatibility 2026-03-17 nebo novější, když nodejs_compat je zapnuté.

Viz Dokumentace Node.js ↗ další podrobnosti o node:child_process API.

enable_nodejs_perf_hooks_module příznak zapíná node:perf_hooks modul ve Workers. Tento příznak zároveň implicitně zapíná globální třídy Performance (PerformanceEntry, PerformanceMark, PerformanceMeasure, PerformanceResourceTiming, PerformanceObserver, a PerformanceObserverEntryList).

Tento příznak se automaticky povolí pro Workery používající datum kompatibility 2026-03-17 nebo novější, když nodejs_compat je zapnuté.

Viz Dokumentace Node.js ↗ další podrobnosti o node:perf_hooks API.

enable_nodejs_readline_module příznak zapíná node:readline stub modulu ve Workers.

Tento příznak se automaticky povolí pro Workery používající datum kompatibility 2026-03-17 nebo novější, když nodejs_compat je zapnuté.

Viz Dokumentace Node.js ↗ další podrobnosti o node:readline API.

enable_nodejs_repl_module příznak zapíná node:repl stub modulu ve Workers.

Tento příznak se automaticky povolí pro Workery používající datum kompatibility 2026-03-17 nebo novější, když nodejs_compat je zapnuté.

Viz Dokumentace Node.js ↗ další podrobnosti o node:repl API.

enable_nodejs_tty_module příznak zapíná node:tty stub modulu ve Workers.

Tento příznak se automaticky povolí pro Workery používající datum kompatibility 2026-03-17 nebo novější, když nodejs_compat je zapnuté.

Viz Dokumentace Node.js ↗ další podrobnosti o node:tty API.

enable_nodejs_v8_module příznak zapíná node:v8 stub modulu ve Workers.

Tento příznak se automaticky povolí pro Workery používající datum kompatibility 2026-03-17 nebo novější, když nodejs_compat je zapnuté.

Viz Dokumentace Node.js ↗ další podrobnosti o node:v8 API.

enable_nodejs_worker_threads_module příznak zapíná node:worker_threads stub modulu ve Workers.

Tento příznak se automaticky povolí pro Workery používající datum kompatibility 2026-03-17 nebo novější, když nodejs_compat je zapnuté.

Viz Dokumentace Node.js ↗ další podrobnosti o node:worker_threads API.

Tento příznak řídí výchozí hodnotu binaryType vlastnost na WebSocket, což zase určuje, jak jsou binární rámce doručovány do message událost. Když je příznak aktivní, binaryType má výchozí hodnotu "blob" a binární rámce přicházejí jako Blob ↗ objekty odpovídající Specifikace WebSocket ↗ a standardní chování prohlížeče. Bez tohoto příznaku binaryType má výchozí hodnotu "arraybuffer" a binární rámce přicházejí jako ArrayBuffer ↗, což odpovídá dosavadnímu chování runtime.

binaryType vlastnost samotná je dostupná na každém WebSocket bez ohledu na příznak. Přiřazení hodnoty přepíše výchozí nastavení pro daný WebSocket:

const resp = await fetch("https://example.com", {
  headers: { Upgrade: "websocket" },
});
const ws = resp.webSocket;

// Opt back into ArrayBuffer delivery before calling accept().
ws.binaryType = "arraybuffer";
ws.accept();

ws.addEventListener("message", (event) => {
  // event.data is an ArrayBuffer for binary frames.
});

Pokud ještě nejste připraveni k migraci a chcete ponechat ArrayBuffer jako výchozí hodnotu pro každý WebSocket ve vašem Workeru přidejte no_websocket_standard_binary_type příznak do svého Konfigurační soubor Wrangler.

Tento příznak nemá žádný vliv na hibernovatelný WebSocket Durable Object webSocketMessage handler, který vždy přijímá binární data jako ArrayBuffer.

Když queue_expose_error_codes je povoleno, Queue operace budou obsahovat podrobné informace o chybách, včetně kódů chyb a jejich příčin, což usnadní programové zpracování a diagnostiku chyb souvisejících s frontou.

Když server odešle rámec WebSocket Close, runtime prostředí Workers nyní automaticky odešle reciproční rámec Close a přejde readyState na CLOSED před vyvoláním close událost. Ta odpovídá Specifikace WebSocket ↗ a chování prohlížeče.

Dříve přijetí serverem iniciovaného rámce Close ponechalo WebSocket ve stavu CLOSING a vyžadovalo, aby aplikace volala close() samo o sobě. Když je tento flag aktivní, už nemusíte volat close() ve vašem close obslužná rutina události. Runtime řeší ukončovací handshake automaticky.

const [client, server] = Object.values(new WebSocketPair());
server.accept();

server.addEventListener("close", (event) => {
  // readyState is already CLOSED — no need to call server.close().
  console.log(server.readyState); // WebSocket.CLOSED
  console.log(event.code); // 1000
  console.log(event.wasClean); // true
}, { once: true });

Pokud přesto voláte close() uvnitř handleru, volání se tiše ignoruje. Stávající kód, který ručně odpovídá na rámce Close, se tak po aktualizaci data kompatibility nerozbije.

Automatické chování při uzavírání může narušit proxování WebSocket. Když Worker funguje jako proxy mezi klientem a backendem, dřívější chování mu umožňovalo zaznamenat rámec Close z backendu, aniž by runtime spojení ukončil, čímž Worker získal čas na koordinaci čistého uzavření na straně klienta. Aby tento model fungoval, accept() metoda nyní přijímá možnost allowHalfOpen. Zavolejte ws.accept({ allowHalfOpen: true }) pro obnovení starého chování half-open bez ohledu na příznak kompatibility.

const [client, server] = Object.values(new WebSocketPair());

// Opt into half-open mode for proxying
server.accept({ allowHalfOpen: true });

server.addEventListener("close", (event) => {
  // With allowHalfOpen true, readyState is still CLOSING here,
  // giving you time to coordinate the close on the other side.
  console.log(server.readyState); // WebSocket.CLOSING

  // Manually close when ready.
  server.close(1000, "done");
}, { once: true });

Mějte na paměti, že neexistuje odpovídající možnost k WebSocket konstruktor. WebSockety vytvořené pomocí new WebSocket bude vždy automaticky odpovídat na closes poté, co tato flag nabude účinnosti. WebSockets vytvořené tímto způsobem jsou automaticky "accepted", takže není možnost předat tuto možnost accept(). Pokud vytváříte WebSocket pomocí new WebSocket, ale potřebujete poloviční uzavírání (half-open), budete muset přejít na fetch() místo toho.

// This does not allow half-open:
let ws = new WebSocket("wss://example.com");

// But you can do this instead:
let resp = await fetch("https://example.com", {
  headers: { "Upgrade": "websocket" }
});
if (!resp.webSocket) {
  throw new Error("WebSocket handshake not accepted");
}
let ws = resp.webSocket;
ws.accept({ allowHalfOpen: true });

Další informace naleznete v Dokumentace WebSocket API.

Když text_decoder_cjk_decoder je povoleno, vyhrazený CJK TextDecoder implementace se používá pro přepisy kódování CJK a zpracování úvodních bajtů Big5 namísto starší cesty kódu založené výhradně na ICU. Tím se zlepšuje shoda se specifikací při dekódování textu CJK.

Když unhandled_rejection_after_microtask_checkpoint je povoleno, unhandledrejection zpracování události se odloží, dokud se nedokončí kontrolní bod mikroúlohy. Tím se zabrání chybným vyvoláním u vícetaktových řetězců příslibů, kde je obslužná rutina zamítnutí přidána až v pozdější mikroúloze.

Dříve mohlo zpracování unhandled rejection proběhnout předčasně, ještě před zpracováním všech microtasks v aktuálním checkpointu, což vedlo k falešným unhandledrejection události pro přísliby, které byly skutečně obslouženy.

Když websocket_close_reason_byte_limit je povoleno, WebSocket.close() vyvolá SyntaxError DOMException pokud reason string překročí 123 bajtů při kódování UTF-8, jak vyžaduje specifikace WHATWG WebSocket ↗ a RFC 6455, oddíl 5.5 ↗.

Workers dříve umožňoval libovolně dlouhé důvody uzavření spojení bez validace.

S delete_all_deletes_alarm příznak nastaven, volání deleteAll() nad úložištěm Durable Object smaže veškerý aktivní alarm i všechna uložená data. Dříve deleteAll() mazalo pouze data uložená uživatelem a pro alarmy byl potřeba samostatný deleteAlarm() volání k odebrání. Tato změna platí jak pro Durable Objects s úložištěm KV, tak pro Durable Objects s úložištěm SQLite.

Když text_decoder_replace_surrogates je povoleno, UTF-16le TextDecoder nahradí osamocené náhradní znaky (lone surrogates) znakem U+FFFD (náhradní znak Unicode) podle požadavků Standard Encoding ↗. Dříve byly osamocené náhradní znaky (surrogates) předávány beze změny, což vytvářelo nesprávně formované řetězce.

Když fetch_iterable_type_support je povoleno, synchronní i asynchronní iterovatelné objekty lze předat jako tělo fetch() Request nebo Response a bude se přes ni správně iterovat.

Dříve byly synchronní iterovatelné objekty jako Arrays přijímány, ale byly převedeny na řetězec (např. [1, 2, 3] by se stalo "1,2,3"), a asynchronní iterovatelné objekty by byly považovány za běžné objekty a vůbec by se neiterovaly. Když je tento příznak povolený, iterovatelné objekty se správně zpracují jako streamovaný obsah těla.

Všimněte si, že Arrays se nyní budou zpracovávat jako iterovatelné objekty místo převodu na řetězec, což je změna narušující zpětnou kompatibilitu u kódu, který se spoléhal na původní chování.

Když enable_nodejs_global_timers je povoleno, setTimeout, setInterval, clearTimeout, a clearInterval vracejí kompatibilní s Node.js Timeout objekty s metodami jako refresh(), ref(), unref(), a hasRef(), což odpovídá chování node:timers.

Tento příznak vyžaduje nodejs_compat aby bylo povoleno, a je automaticky povoleno pro Workery používající datum kompatibility 2026-02-10 nebo novější, pokud nodejs_compat je zapnuté.

Viz Dokumentace Node.js ↗ další podrobnosti o timer API.

enable_nodejs_dgram_module příznak zapíná node:dgram stub modulu ve Workers.

Tento příznak se automaticky povolí pro Workery používající datum kompatibility 2026-01-29 nebo novější, když nodejs_compat je zapnuté.

Viz Dokumentace Node.js ↗ další podrobnosti o node:dgram API.

enable_nodejs_inspector_module příznak zapíná node:inspector stub modulu ve Workers.

Tento příznak se automaticky povolí pro Workery používající datum kompatibility 2026-01-29 nebo novější, když nodejs_compat je zapnuté.

Viz Dokumentace Node.js ↗ další podrobnosti o node:inspector API.

enable_nodejs_sqlite_module příznak zapíná node:sqlite stub modulu ve Workers.

Tento příznak se automaticky povolí pro Workery používající datum kompatibility 2026-01-29 nebo novější, když nodejs_compat je zapnuté.

Viz Dokumentace Node.js ↗ další podrobnosti o node:sqlite API.

enable_nodejs_stream_wrap_module příznak zapíná node:_stream_wrap stub modulu ve Workers.

Tento příznak se automaticky povolí pro Workery používající datum kompatibility 2026-01-29 nebo novější, když nodejs_compat je zapnuté.

Když require_returns_default_export je povoleno, require() vrátí výchozí export modulu, pokud existuje. Pokud výchozí export neexistuje, vrátí se místo toho měnitelná kopie objektu module namespace.

Toto odpovídá chování, které Node.js používá pro require(esm), kde je vrácen výchozí export, pokud je k dispozici. Tento příznak je užitečný pro frameworky jako Next.js, které očekávají možnost upravovat exporty modulů.

Dříve, require() vždy vracelo objekt jmenného prostoru modulu (objekt jako {default: module.exports}).

Mění sémantiku vlastnictví RPC stubů vložených v parametrech RPC volání a opravuje problémy s kompatibilitou s Cap'n Web ↗.

Když systém Workers RPC byla poprvé zavedena, měly RPC stuby vložené do parametrů nebo návratové hodnoty jiného volání převedeno vlastnictví. To znamená, že původní stub byl implicitně uvolněn a do cíle byla doručena jeho duplicitní kopie.

To se ale špatně kombinuje s dalším pravidlem: u volané strany se všechny stubs přijaté v parametrech volání po návratu volání automaticky disposed. Kombinace těchto dvou pravidel znamená, že pokud proxujete volání (tedy implementace RPC jen předá stejné parametry v dalším RPC volání), stubs v parametrech se disposed dvakrát. Horší je, že pokud si konečný příjemce stubu chce po skončení volání ponechat duplikát, nemusí to fungovat, protože kopie stubu ve vrstvě proxy se stejně disposed, čímž se spojení přeruší.

Z tohoto důvodu čistě JS implementace Cap'n Web přešla na pravidlo, že stubs v params NEPŘEDÁVAJÍ vlastnictví, pouze se duplikují. Tento compat flag upravuje vestavěné RPC ve Workers Runtime tak, aby odpovídalo chování Cap'n Web.

Jedním z běžných případů použití, které toto řeší, jsou klienti přihlašující se k odběru callbacků z Durable Object přes Cap'n Web. V tomto případě klientská aplikace předá callback funkci přes WebSocket Cap'n Web bezstavovému Workeru, který stub dále přeposílá přes Workers RPC do Durable Object. Durable Object uchovává dup() stubu, aby ho bylo možné později znovu zavolat a informovat klienta o událostech. Před zavedením tohoto příznaku to bohužel nefungovalo: jakmile funkce subscribe sama skončila, stub Cap'n Web ve stateless workeru se uvolnil (protože šlo o parametr volání, které skončilo, a nebyl dup(), tedy nebyl v kontextu bezstavového workeru znovu duplikován). Když se Durable Object později pokusil zavolat callback odběru, obdržel by chybu „Error: RPC stub used after being disposed“, i přesto, že byl pečlivě dup(), tedy stub na jeho konci znovu zduplikoval.

Když fetch_iterable_type_support_override_adjustment je povoleno, objekty předané jako tělo fetch() Request nebo Response které jsou synchronně iterovatelné, ale zároveň mají vlastní toString nebo Symbol.toPrimitive metoda nebude považována za iterovatelnou. Místo toho bude zpracována jako objekt převedený na řetězec, což odpovídá předchozímu chování u takových objektů.

Tento příznak zpřesňuje chování zavedené fetch_iterable_type_support příznak a automaticky se povolí, když fetch_iterable_type_support je povoleno po 2026-01-15.

Když strip_bom_in_read_all_text je povoleno, readAllText() metoda u streamů odstraní úvodní byte order mark (BOM) v kódování UTF-8, pokud je přítomen, což odpovídá očekávanému chování podle standardů webové platformy.

Dříve byl do vráceného řetězce zahrnut BOM, což mohlo při parsování textového obsahu způsobit neočekávané chování.

enable_nodejs_cluster_module příznak zapíná node:cluster stub modulu ve Workers.

Tento příznak se automaticky povolí pro Workery používající datum kompatibility 2025-12-04 nebo novější, když nodejs_compat je zapnuté.

Viz Dokumentace Node.js ↗ další podrobnosti o node:cluster API.

enable_nodejs_domain_module příznak zapíná node:domain stub modulu ve Workers. Mějte na paměti, že node:domain je zastaralá již v samotném Node.js.

Tento příznak se automaticky povolí pro Workery používající datum kompatibility 2025-12-04 nebo novější, když nodejs_compat je zapnuté.

Viz Dokumentace Node.js ↗ další podrobnosti o node:domain API.

enable_nodejs_punycode_module příznak zapíná node:punycode modul ve Workers. Mějte na paměti, že node:punycode je zastaralá již v samotném Node.js.

Tento příznak se automaticky povolí pro Workery používající datum kompatibility 2025-12-04 nebo novější, když nodejs_compat je zapnuté.

Viz Dokumentace Node.js ↗ další podrobnosti o node:punycode API.

enable_nodejs_trace_events_module příznak zapíná node:trace_events stub modulu ve Workers.

Tento příznak se automaticky povolí pro Workery používající datum kompatibility 2025-12-04 nebo novější, když nodejs_compat je zapnuté.

Viz Dokumentace Node.js ↗ další podrobnosti o node:trace_events API.

enable_nodejs_wasi_module příznak zapíná node:wasi stub modulu ve Workers.

Tento příznak se automaticky povolí pro Workery používající datum kompatibility 2025-12-04 nebo novější, když nodejs_compat je zapnuté.

Viz Dokumentace Node.js ↗ další podrobnosti o node:wasi API.

Když enable_fast_jsg_struct je povoleno, interní typy struktur používané rozhraními API běhového prostředí Workers se vytvářejí pomocí efektivnějšího vzoru, který zkracuje dobu vytváření objektů.

Volitelná pole však budou explicitně nastavena na undefined místo toho, aby byla z objektu zcela vynechána, což představuje pozorovatelnou změnu chování. Kód, který kontroluje přítomnost vlastnosti pomocí "key" in obj nebo Object.hasOwn(obj, "key") se může chovat jinak, protože volitelná pole, která dříve chyběla, budou nyní přítomna s hodnotou undefined.

Pro kontrolu hodnoty upřednostněte obj.key !== undefined přes "key" in obj.

Tento příznak povoluje ctx.exports API, který obsahuje automaticky nakonfigurované loopback bindingy pro exporty vašeho Workeru na nejvyšší úrovni. Díky tomu nemusíte konfigurovat explicitní bindingy pro váš WorkerEntrypoints a Durable Object namespaces definované ve stejném Workeru.

Tento příznak povolí Workers Tracing ve výchozím nastavení, pokud máte ve svém konfiguračním souboru Wrangleru nastaveno následující:

{
	"observability": {
		"enabled": true
	}
}

Automatické trasování můžete také výslovně zapnout bez příznaku a se staršími daty kompatibility nastavením následujícího:

{
	"observability": {
		"traces": {
			"enabled": true
		}
	}
}

enable_nodejs_vm_module příznak zapíná node:vm stub modulu ve Workers.

Tento příznak se automaticky povolí pro Workery používající datum kompatibility 2025-10-01 nebo novější, když nodejs_compat je zapnuté.

Viz Dokumentace Node.js ↗ další podrobnosti o node:vm API.

enable_nodejs_console_module příznak zapíná node:console modul ve Workers.

Tento příznak se automaticky povolí pro Workery používající datum kompatibility 2025-09-21 nebo novější, když nodejs_compat je zapnuté.

Viz Dokumentace Node.js ↗ další podrobnosti o node:console API.

Když enable_validate_workflow_entrypoint je povoleno, provádějí se další ověřovací kontroly, aby bylo zajištěno, že Workflows jsou definovány a používány správně. Díky tomu lze chyby v konfiguraci odhalit už při nahrávání, a ne až za běhu.

enable_nodejs_fs_module příznak zapíná node:fs modul ve Workers.

Tento příznak se automaticky povolí pro Workery používající datum kompatibility 2025-09-15 nebo novější, když nodejs_compat je zapnuté.

Viz Dokumentace Node.js ↗ další podrobnosti o node:fs API.

enable_nodejs_os_module příznak zapíná node:os modul ve Workers.

Tento příznak se automaticky povolí pro Workery používající datum kompatibility 2025-09-15 nebo novější, když nodejs_compat je zapnuté.

Viz Dokumentace Node.js ↗ další podrobnosti o node:os API.

Je-li povoleno po 2025-09-15, enable_nodejs_process_v2 příznak spolu s nodejs_compat příznak kompatibility zajišťuje komplexní implementaci kompatibilní s Node.js process implementace, která nahrazuje předchozí minimální implementaci procesu poskytující pouze omezené nextTick, env, exit, getBuiltinModule, platform a features vlastnosti.

Chcete-li po datu kompatibility pokračovat v používání předchozí minimální implementace, nastavte disable_nodejs_process_v2 příznak místo toho.

Většina vlastností objektu process podporovaných v Node.js je implementována, kde je to možné, přičemž nepodporované funkce mají exporty typu undefined. Viz dokumentace k procesu pro podrobnosti implementace specifické pro Workers.

enable_nodejs_http_server_modules příznak zpřístupňuje HTTP serverové moduly Node.js, jako například node:_http_server ve Workers.

disable_nodejs_http_server_modules příznak zakazuje dostupnost těchto serverových modulů.

Tím se umožní kompatibilita s knihovnami Node.js a existujícím kódem, který používá standardní API HTTP serveru Node.js. Dostupná funkcionalita zahrnuje:

• http.createServer() pro vytváření HTTP serverů
• http.Server třída pro instance serveru
• http.ServerResponse pro zpracování odpovědí serveru

Tento příznak je nutné použít v kombinaci s enable_nodejs_http_modules příznak, kterým povolíte všechny funkce node:http.

Tento příznak se automaticky povolí pro Workery používající datum kompatibility 2025-09-01 nebo novější, když nodejs_compat je zapnuté.

Viz Dokumentace Node.js ↗ další podrobnosti o Node.js HTTP API.

enable_nodejs_http2_module příznak zapíná node:http2 stuby modulů ve Workers.

Tento příznak se automaticky povolí pro Workery používající datum kompatibility 2025-09-01 nebo novější, když nodejs_compat je zapnuté.

Viz Dokumentace Node.js ↗ další podrobnosti o node:http2 API.

Když remove_nodejs_compat_eol je povoleno, rozhraní API, jejichž podpora v Node.js skončila, budou pro Workers odstraněna. Když je zakázáno, rozhraní API jsou přítomná, ale mohou být nefunkčními zástupnými objekty.

Tento příznak je souhrnný. Jakmile v konkrétních verzích Node.js dosáhnou další API konce podpory (EOL), přidávají se nové příznaky kompatibility specifické pro danou verzi (například remove_nodejs_compat_eol_v22, remove_nodejs_compat_eol_v23, a remove_nodejs_compat_eol_v24) které tento příznak od svých příslušných dat implikuje.

Tento příznak se automaticky povolí pro Workery používající datum kompatibility 2025-09-01 nebo novější, když nodejs_compat je zapnuté.

Když remove_nodejs_compat_eol_v23 je povoleno, rozhraní API, jejichž podpora v Node.js 23.x skončila (konec podpory červen 2025), jsou odstraněna.

Tento příznak se automaticky povolí, když remove_nodejs_compat_eol_v24 příznak je povolen po 2025-09-01.

Když strip_authorization_on_cross_origin_redirect je povoleno, Authorization hlavička se při přesměrování na jiný origin automaticky odstraní. Toto chování vyžaduje aktuální Specifikace Fetch API ↗.

Tento požadavek byl do specifikace Fetch přidán v roce 2022, poté, co Cloudflare Workers původně implementoval zpracování fetch. Workers tento požadavek původně neimplementovaly, proto je nové chování podmíněno compatibility flag.

Původní chování nebylo samo o sobě nebezpečné a za určitých okolností mohlo být žádoucí. Jde například o případ, kdy API vyžadující autorizaci potřebuje přesměrovat na nový hostitel a přitom chce, aby klient zároveň odeslal své přihlašovací údaje. Podle nového chování takové přesměrování přihlašovací údaje automaticky neobsahuje. Původní chování však mohlo při přesměrování na nedůvěryhodné origin servery vést k neúmyslnému úniku přihlašovacích údajů.

Chcete-li zachovat staré chování, nastavte retain_authorization_on_cross_origin_redirect příznak.

enable_nodejs_http_modules příznak zpřístupňuje Node.js node:http a node:https moduly ve Workers (pouze klientská API).

disable_nodejs_http_modules příznak zakazuje dostupnost těchto modulů.

Tím se umožní kompatibilita s knihovnami Node.js a existujícím kódem, který používá standardní API node:http a node:https pro vytváření požadavků HTTP. Dostupná funkcionalita zahrnuje:

• http.request() a https.request() pro vytváření požadavků HTTP/HTTPS
• http.get() a https.get() pro vytváření požadavků GET
• Objekty požadavku a odpovědi se standardními Node.js API
• Podpora standardních metod, hlaviček a možností HTTP

Viz Dokumentace Node.js ↗ pro další podrobnosti o Node.js API.

Když expose_global_message_channel příznak nastaven, Workers zpřístupní MessageChannel a MessagePort konstruktory globálně.

Když no_expose_global_message_channel příznak nastaven, Workers je nezpřístupní.

Když python_no_global_handlers příznak nastaven, Python Workers vypnou globální handlery a jejich použití vynutí prostřednictvím výchozích tříd entrypoint.

Když povolíte cache_no_cache_enabled příznak kompatibility můžete zadat no-cache hodnotu pro cache vlastnost rozhraní Request. Pokud tento kompatibilní příznak není povolen, nebo cache_option_disabled je nastaveno, runtime Workers vyvolá TypeError se slovy Unsupported cache mode: no-cache.

Když je tento příznak povolen, můžete Cloudflare pokynout, aby vynutil revalidaci odpovědi ze subrequestu, který odešlete z Workeru pomocí fetch() API:

Když no-cache je zadáno:

• Všechny požadavky obsahují hlavičky Pragma: no-cache a Cache-Control: no-cache jsou na nich nastaveny.

• Podpožadavky na origin servery, které nejsou hostovány na Cloudflare, nutí cache Cloudflare k revalidaci s origin serverem.

Revalidace s originem znamená, že požadavek Workeru nejprve vyhledá shodu ve vyrovnávací paměti Cloudflare a poté:

• Pokud dojde ke shodě, na origin server se odešle podmíněný požadavek bez ohledu na to, zda je shoda aktuální, nebo zastaralá. Pokud se prostředek nezměnil, vrátí se jeho verze uložená v mezipaměti. Pokud se prostředek změnil, stáhne se z origin serveru, aktualizuje se v mezipaměti a vrátí se.
• Pokud ke shodě nedojde, Workers odešle na origin server standardní požadavek a odpověď uloží do mezipaměti.

Příklady s použitím cache: 'no-cache':

const response = await fetch("https://example.com", { cache: "no-cache" });

Hodnotu cache lze také nastavit na Request objekt.

const request = new Request("https://example.com", { cache: "no-cache" });
const response = await fetch(request);

Když set_event_target_this příznak nastaven, Workers nastaví this hodnotu obslužných rutin událostí na EventTarget instance, na které je událost odesílána. To je v souladu se specifikací.

Když pak no_set_event_target_this příznak nastaven, Workers nenastaví this hodnota obslužných rutin událostí a bude undefined místo toho.

Původní verze hlaviček odesílaných do edgeworkeru byla u konkrétních názvů hlaviček, jako To a Cc, zkrácena na jedinou hodnotu. S set_forwardable_email_full_headers příznak nastaven, Workers obdrží úplné hodnoty hlaviček ve skriptu workeru.

pedantic_wpt příznak zapíná přísný soulad s Web Platform Tests (WPT) ve Workers. Zatím to ovlivňuje pouze Event a EventTarget API, ale v budoucnu bude rozšířeno na další API. Pro tento příznak není ve výchozím nastavení určeno datum aktivace.

Rámec AsyncLocalStorage může zachytávat hodnoty, které jsou svázané s aktuálním kontextem požadavku. Uživatel to nemá vždy plně pod kontrolou, protože rámec úložiště ALS se používá i k šíření interních rozpětí trasování (trace spans) a hodnot zadaných uživatelem. Když se bind_asynclocalstorage_snapshot_to_request příznak je nastaven, runtime naváže snapshot / vázané funkce na aktuální kontext požadavku a vyvolá chybu, pokud jsou vázané funkce volány mimo požadavek, ve kterém byly vytvořeny.

do_not_bind_asynclocalstorage_snapshot_to příznak toto chování vypíná.

throw_on_unrecognized_import_assertion příznak řídí, jak Workers zpracovávají atributy importu, které runtime nerozpozná. Dříve Workers všechny nerozpoznané atributy importu ignorovaly, což není v souladu se specifikací. Od runtime se očekává, že při výskytu nerozpoznaného atributu importu vyhodí chybu.

Když ignore_unrecognized_import_assertion příznak nastaven, Workers budou ignorovat nerozpoznané atributy importu.

Když allow_eval_during_startup příznak nastaven, Workers mohou použít eval() a new Function(text) během fáze spouštění skriptu Workeru. To umožňuje dynamické spouštění kódu na začátku životního cyklu Workeru.

Když disallow_eval_during_startup příznak nastaven, použití eval() nebo new Function(text) během fáze spouštění vyvolá chybu.

Když použijete enable_request_signal příznak kompatibility můžete připojit event listener k Request objekty pomocí signal vlastnost ↗. Díky tomu můžete provádět úlohy ve chvíli, kdy klient zruší požadavek na váš Worker.

Když cache_api_request_cf_overrides_cache_rules je povoleno, nastavení mezipaměti zadaná v cf objekt požadavku předaného do Cache API přepíše pravidla cache. Platí to pouze pro weby vlastněné uživatelem nebo weby v režimu šedého mraku (grey-clouded).

Toto je protějšek Cache API k request_cf_overrides_cache_rules příznak, který se vztahuje na fetch() API.

Když enable_navigator_language příznak nastaven, navigator.language vlastnost bude ve Workers k dispozici. Prozatím je hodnota navigator.language bude vždy en.

Když disable_navigator_language příznak nastaven, navigator.language vlastnost nebude k dispozici.

Když disallow_importable_env příznak povolen, Workers nedovolí importovat proměnné prostředí přes cloudflare:workers modul a nenaplní proměnné prostředí v globálním process.env objekt, pokud je povolena kompatibilita s Node.js.

Pro tento příznak není nastaveno žádné výchozí datum povolení.

Umožňuje použití FinalizationRegistry ↗ a WeakRef ↗ vestavěných modulů.

• FinalizationRegistry umožňuje zaregistrovat callback pro úklid, který se spustí po odstranění objektu garbage collectorem.
• WeakRef vytvoří slabou referenci na objekt, což umožňuje jeho uvolnění garbage collectorem, pokud neexistují žádné jiné silné reference.

:::note[Chování] FinalizationRegistry cleanup callbacky se mohou spustit kdykoli během životního cyklu požadavku, a to i po dokončení vašeho volaného handleru (podobně jako ctx.waitUntil()). Tyto callbacky nemají přidružený asynchronní kontext. V jejich rámci nelze provádět žádné I/O operace, včetně odesílání událostí do tail Workeru. :::

:::caution Tyto API jsou v zásadě nedeterministické. Časování a provádění garbage collection jsou nepředvídatelné a vy by se na ně nemělo spoléhat pro klíčovou logiku programu. Navíc callbacky pro úklid registrované pomocí FinalizationRegistry může nikdy se nespustí, mimo jiné v případech, kdy nedojde ke spuštění garbage collection nebo je váš Worker vyřazen. :::

Když request_signal_passthrough příznak nastaven, AbortSignal příchozího požadavku se předá do subrequestů, když je požadavek přeposlán do subrequestu pomocí fetch() API.

Ten no_request_signal_passthrough příznak nastaven, AbortSignal příchozího požadavku se nepředá dál.

Původní URLPattern implementace nebyla plně v souladu s WHATWG URLPattern Standard ↗, což vedlo k řadě problémů hlášených uživateli.

S urlpattern_standard zapnuto, Workers používá implementaci URLPattern odpovídající specifikaci. Jde o změnu, která ruší zpětnou kompatibilitu s původním chováním, a proto je podmíněna příznakem kompatibility.

Pokud používáte URLPattern a po aktualizaci data kompatibility narazíte na neočekávané změny chování, můžete nastavit urlpattern_original pro návrat k předchozí implementaci.

U Workers s statická aktiva a se zapnutým tímto příznakem kompatibility mají navigační požadavky (požadavky, které mají Sec-Fetch-Mode: navigate hlavička) se přednostně obslouží naší logikou pro obsluhu aktiv, i když se nenajde přesná shoda aktiva. To se hodí zejména pro aplikace, které fungují v režimu Režim jednostránkové aplikace (SPA) nebo mít vlastní stránky 404, protože to nyní znamená, že náhradní stránky 200 /index.html a 404 /404.html bude odeslán ještě před spuštěním skriptu Workeru, takže se za něj neúčtuje žádný poplatek.

Bez tohoto příznaku bude runtime i nadále uplatňovat starší chování, kdy pro každý požadavek, který přesně neodpovídá statickému assetu, vyvolá Worker skript (pokud existuje).

Když assets.run_worker_first = true je nastaveno, tento compatibility flag nemá žádný účinek. assets.run_worker_first = true nastavení zajišťuje, že se skript Workeru spustí dříve než jakákoli logika pro obsluhu assetů.

Když povolíte nodejs_compat_populate_process_env příznak kompatibility a nodejs_compat příznak je také povolen, process.env bude naplněn hodnotami ze všech vazeb s textovými nebo JSON hodnotami. Toto znamená, že pokud jste přidali proměnné prostředí, secrets, nebo metadata verze bindings, k těmto hodnotám lze přistoupit přes process.env.

const apiClient = ApiClient.new({ apiKey: process.env.API_KEY });
const LOG_LEVEL = process.env.LOG_LEVEL || "info";

Díky tomu je přístup k těmto hodnotám jednodušší a odpovídá běžným vzorům Node.js, což může snížit pracnost a pomoci s kompatibilitou se stávajícími knihovnami Node.js.

Pokud uživatelé nechtějí, aby tyto hodnoty byly dostupné přes process.env, mohou použít nodejs_compat_do_not_populate_process_env příznak. V takovém případě process.env bude nadále dostupný, hodnoty do něj však nebudou přidávány automaticky.

Pokud disallow_importable_env příznak kompatibility je nastaven, process.env také nebude vyplněno.

Standardně Queues Consumer Workers potvrzují zprávy až poté, co se vyřeší promises předané do ctx.waitUntil() se vyřešily. Toto chování může u konzumentů front, kteří využívají ctx.waitUntil() pro pomalé zpracování zpráv. Výchozí chování je popsáno v Průvodce konfigurací Queues Consumer.

Tento Consumer Worker je příkladem Workeru, který využívá ctx.waitUntil(). Při výchozím chování tento consumer Worker potvrdí dávku zpráv až poté, co se dokončí funkce sleep.

export default {
  async fetch(request, env, ctx) {
    // omitted
  },

  async queue(batch, env, ctx) {
    console.log(`received batch of ${batch.messages.length} messages to queue ${batch.queue}`);
    for (let i = 0; i < batch.messages.length; ++i) {
      console.log(`message #${i}: ${JSON.stringify(batch.messages[i])}`);
    }
    ctx.waitUntil(sleep(30 * 1000));
  }
};

function sleep(ms) {
  return new Promise(resolve => setTimeout(resolve, ms));
}

Pokud queue_consumer_no_wait_for_wait_until příznak povolen, konzumenti Queues už nebudou čekat na promises předané do ctx.waitUntil() se vyřeší, než dojde k potvrzení zpráv. To může zlepšit výkon konzumentů front, kteří využívají ctx.waitUntil(). Pokud je flag povolený, consumer Worker ve výše uvedeném příkladu potvrdí dávku, aniž by čekal na dokončení funkce sleep.

Použití tohoto příznaku neovlivní chování ctx.waitUntil(). ctx.waitUntil() bude nadále prodlužovat dobu života vašeho konzumentského Workeru, aby mohl fungovat i poté, co byla dávka zpráv potvrzena.

Původní implementace TransformStream obsahovala chybu, kvůli které docházelo k selhání signalizace backpressure po prvním zápisu do transformace. Oprava bohužel může způsobit, že stávající kód napsaný jako řešení této chyby přestane fungovat. Proto fixup-transform-stream-backpressure příznak kompatibility je k dispozici pro povolení této opravy.

Oprava je ve výchozím nastavení zapnutá u compatibility dates 2024-12-16 a novějších.

Chcete-li obnovit původní logiku backpressure, vypněte opravu pomocí original-transform-stream-backpressure příznak.

Workers implementuje možnost používat styl Node.js require(...) metoda pro import modulů do balíčku Workeru. Tento mechanismus historicky umožňoval, aby požadované moduly používaly top-level await. To ovšem není s Node.js kompatibilní.

disable_top_level_await_in_require příznak kompatibility způsobí require() selhat, pokud modul používá top-level await. Tento příznak je ve výchozím nastavení povolen pro datum kompatibility 2024-12-02 nebo pozdější.

Chcete-li obnovit původní chování umožňující top-level await, použijte enable_top_level_await_in_require příznak kompatibility.

Když povolíte cache_option_enabled příznak kompatibility můžete zadat hodnotu pro cache vlastnost rozhraní Request. Pokud tento kompatibilní příznak není povolen, nebo cache_option_disabled je nastaveno, runtime Workers vyvolá Error se slovy The 'cache' field on 'RequestInitializerDict' is not implemented.

Když je tento příznak povolen, můžete Cloudflare pokynout, aby neukládal do mezipaměti odpověď ze subrequestu, který odešlete z Workeru pomocí fetch() API:

Jediná možnost cache povolená s cache_option_enabled je 'no-store'. Zadání jakékoli jiné hodnoty způsobí, že Workers runtime vyhodí TypeError se zprávou Unsupported cache mode: <the-mode-you-specified>.

Když no-store je zadáno:

• Všechny požadavky obsahují hlavičky Pragma: no-cache a Cache-Control: no-cache jsou na nich nastaveny.

• Podpožadavky na origin servery, které nejsou hostovány na Cloudflare, obcházejí cache Cloudflare.

Příklady s použitím cache: 'no-store':

const response = await fetch("https://example.com", { cache: "no-store" });

Hodnotu cache lze také nastavit na Request objekt.

const request = new Request("https://example.com", { cache: "no-store" });
const response = await fetch(request);

Když global_fetch_strictly_public příznak kompatibility je povolen, globální fetch() funkce bude směrovat požadavky striktně tak, jako by byly odeslány z veřejného internetu.

To znamená, že požadavky na vlastní zónu Workeru se vrátí zpět k „hlavnímu vchodu“ Cloudflare a budou zpracovány jako požadavek z internetu, což může vést i k opětovnému nasměrování zpět na stejný Worker.

Když global_fetch_strictly_public není povoleno, takové požadavky se směrují na původní server zóny, přičemž se ignorují všechny Workery přiřazené k danému URL a obcházejí se také bezpečnostní nastavení Cloudflare.

V minulosti bylo možné vyřešit promise v nesprávném kontextu požadavku, což mohlo vést k naplánování pokračování promise ve špatném kontextu a způsobit chyby, jež se obtížně diagnostikují.

S handle_cross_request_promise_resolution zapnuto, pokračování příslibů se naplánují ke spuštění ve správném kontextu požadavku, pokud je ještě aktivní, nebo se zahodí s upozorněním, pokud správný kontext už skončil.

Očekává se, že HTTP metody budou psány velkými písmeny. Podle specifikace fetch platí, že pokud je metoda zadána jako get, post, put, delete, head, nebo options, se od implementací očekává, že metodu převedou na velká písmena. U všech ostatních názvů metod se obecně očekává, že vyvolají chybu jako nerozpoznané (například patch by bylo chybou, když PATCH je přijata). To je poněkud restriktivní, i když to odpovídá specifikaci. Tento příznak upravuje chování tak, že před analýzou převede všechny metody na velká písmena, takže metoda je vždy rozpoznána, pokud jde o známou metodu.

Chcete-li obnovit standardní chování, použijte no_upper_case_all_http_methods příznak kompatibility.

Byla provedena změna, která nastavuje Symbol.toStringTag na všech objektech Workers API, aby se opravilo několik chyb v souladu se specifikací. Tato změna se však ukázala být náročnější na zpětnou kompatibilitu, než se očekávalo. do_not_set_tostring_tag compat příznak obnoví původní chování pro data kompatibility 2024-09-26 nebo starší.

nodejs_zlib příznak zapíná node:zlib modul ve Workers.

Tento příznak se automaticky povolí pro Workery používající datum kompatibility 2024-09-23 nebo novější, když nodejs_compat je zapnuté.

Viz Dokumentace Node.js ↗ další podrobnosti o node:zlib API.

Když je tento příznak povolen a při vytváření subrequestu zadáte port pomocí fetch() API, použije se číslo portu, které zadáte.

Když odešlete subrequest na web, který používá Cloudflare („Orange Clouded“), lze zadat pouze porty podporované reverzní proxy Cloudflare lze zadat. Pokud se pokusíte zadat nepodporovaný port, bude ignorován.

Když odešlete subrequest na web, který nepoužívá Cloudflare („Grey Clouded“), lze zadat libovolný port.

Například:

const response = await fetch("https://example.com:8000");

S allow_custom_ports by výše uvedený příklad načetl https://example.com:8000 místo https://example.com:443.

Mějte na paměti, že vytvoření klienta WebSocket voláním new WebSocket(url) bude tuto flag také respektovat.

Při použití původní implementace WritableStream („interní“ streamy) abort() operace se dříve zpracovávala líně, což znamenalo, že se fronta čekajících zápisů nevyprázdnila, dokud nebyla znovu zpracována. Toto chování mohlo způsobit zaseknutí streamu, pokud consumer přestal odebírat data.

S internal_writable_stream_abort_clears_queue zapnuto, fronta se okamžitě vyprázdní při abort(), což zabraňuje zaseknutí v případech, kdy konzument přestal zpracovávat zápisy.

Při volání response.blob.type(), typ MIME se nyní správně určí z content-type hlavičky podle specifikace WHATWG ↗.

fetch_standard_url příznak způsobí, že fetch() použít WHATWG URL Standard ↗ pravidel parsování. Původní implementace vyvolala výjimku TypeError: Fetch API cannot load chyby u některých adres URL, u kterých je standardní parsování nevyvolá, například když je před adresou URL bílý znak. Chyby URL se nyní vyvolají ihned při volání new Request() s neplatnou URL adresou. Dříve se chyby URL vyhazovaly pouze jednou fetch() byla volána.

V původní implementaci BYOB ("Bring your own buffer") ReadableStreams, read() metoda by vrátila undefined když byl stream uzavřen a nebyla k dispozici žádná další data ke čtení. Toto chování nebylo v souladu se standardem ReadableStream chování, které vrací prázdný Uint8Array při uzavření streamu.

Když internal_stream_byob_return_view příznak použit, BYOB read() implementuje standardní chování.

const resp = await fetch('https://example.org');
const reader = resp.body.getReader({ mode: 'byob' });
await result = await reader.read(new Uint8Array(10));

if (result.done) {
  // The result gives us an empty Uint8Array...
  console.log(result.value.byteLength); // 0

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

Když brotli_content_encoding příznak kompatibility je povolen, Workers podporuje br kódování obsahu a může požadovat a odpovídat daty kódovanými pomocí Brotli ↗ kompresní algoritmus. Ten snižuje množství dat, která je potřeba načíst, a lze ho použít k předání původních komprimovaných dat klientovi. Více informací najdete v Fetch API dokumentace s podrobnostmi.

Když je tento příznak zapnutý, Durable Object stuby a Service Bindings podporují RPC. To znamená, že tyto objekty nyní vypadají, jako by definovaly úplně každý název metody. Zavolání jakéhokoli názvu metody odešle RPC vzdálenému Durable Object nebo službě Worker.

Pro většinu aplikací nebude mít tato změna žádný dopad, pokud ji nevyužíváte. Je však možné, že některý existující kód bude ovlivněn, pokud explicitně kontroluje existenci názvů metod, které dříve na těchto typech nebyly definovány. V praxi jsme se například setkali s kódem, který iteruje přes vazby a snaží se automaticky rozpoznat jejich typy podle toho, jaké metody implementují. Takový kód nyní uvidí, že Service Bindings implementují každou metodu, a proto si je může mylně vyložit jako nějaký jiný typ. V případech, které jsme zaznamenali, byl dopad neškodný (nic se ve skutečnosti nerozbilo), ale z opatrnosti jsme tuto změnu prozatím skryli za příznak.

S unwrap_custom_thenables příznak nastaven, různá API Workers, která přijímají promises, budou správně zpracovávat i vlastní thenables (objekty s then metoda), které nejsou nativními promises, ale mají být za takové považovány). Například waitUntil metoda v rámci ExecutionContext objekt bude správně zpracovávat vlastní thenables, což umožňuje jejich použití místo nativních promises.

async fetch(req, env, ctx) {
  ctx.waitUntil({ then(res) {
    // Resolve the thenable after 1 second
    setTimeout(res, 1000);
  } });
  // ...
}

Durable Object stuby a Service Bindings oba implementují fetch() metoda, která se chová podobně jako globální fetch() metoda, ale požadavky se místo toho odesílají na cíl reprezentovaný objektem, nikoli na základě směrování podle URL adresy.

V minulosti API objekty, které měly takový fetch() metoda měla také metody get(), put(), a delete(). Tyto metody byly tenkými wrappery kolem fetch() což by provedlo odpovídající HTTP metodu a podle potřeby automaticky zajistilo zápis/čtení těl requestu/response.

Tyto metody byly velmi ranou myšlenkou z doby před mnoha lety, nikdy ale nebyly skutečně zdokumentovány, a proto se používaly jen zřídka (pokud vůbec). Povolením fetcher_no_get_put_delete, nebo nastavením data kompatibility na nebo po 2024-03-26 tyto metody pro váš Worker zakazuje.

Tato změna otevírá cestu k tomu, abyste v budoucnu mohli definovat vlastní metody s těmito názvy. Bez této změny byste nemohli definovat vlastní get, put, a delete metody, protože by byly v konfliktu s těmito vestavěnými pomocnými metodami.

S queues_json_messages příznak nastaven, vazby Queue serializují hodnoty předané do send() nebo sendBatch() do formátu JSON ve výchozím nastavení (pokud není zadán žádný konkrétní contentType je zadáno).

Potlačuje globální importScripts() funkci. Tato metoda byla součástí globálního rozsahu Workers, ale byla výslovně označena jako neimplementovaná. Přítomnost funkce však mohla u některých knihoven způsobovat problémy. Tento příznak kompatibility funkci z globálního rozsahu odstraňuje.

Zpřístupňuje rozhraní Node.js AsyncLocalStorage ↗ API ve Workers.

Tento příznak zapíná plnohodnotnou podporu Pythonu. Python Workers implementují většinu Pythonu standardní knihovna, podporují všechny vazby, proměnná prostředí, a secrets, a integraci s objekty a funkcemi JavaScriptu prostřednictvím foreign function interface.

V rozhraní WebCrypto API publicExponent pole algoritmu klíčů RSA dříve bylo ArrayBuffer. Pomocí tohoto flagu publicExponent je Uint8Array jak vyžaduje specifikace.

Nastavená hodnota na vectorize_query_metadata_optional znamená, že operace dotazu Vectorize by měla přijímat novější argumenty s returnValues a returnMetadata zadán samostatně namísto staršího argumentu returnVectors. Tím se mění i formát návratové hodnoty. Pokud byly hodnoty vektoru označeny k vrácení, návratová hodnota je nyní zploštělý (flattened) vektorový objekt s score připojen tam, kde dříve obsahoval vnořený vektorový objekt.

Workers runtime zpočátku kompresi WebSocket nepodporoval, protože ji neumožňovala ani první implementace WebSocket. Runtime proto historicky odstraňoval nebo ignoroval Sec-WebSocket-Extensions hlavičku, nyní je ale schopen plně dodržovat WebSocket Compression RFC. Protože mnoho klientů pravděpodobně odesílá Sec-WebSocket-Extensions: permessage-deflate svým Workers ještě dnes (new WebSocket(url) to v prohlížečích nastavuje automaticky), rozhodli jsme se zachovat původní chování, pokud tento příznak chybí.

Pokud je tento příznak přítomen, prostředí Workers runtime dokáže používat WebSocket Compression jak u příchozích, tak u odchozích WebSocket připojení.

Stejně jako v prohlížečích, volání new WebSocket(url) ve Workeru automaticky nastaví Sec-WebSocket-Extensions: permessage-deflate hlavička. Pokud používáte nestandardní fetch() API k získání WebSocketu můžete zahrnout Sec-WebSocket-Extensions hlavičku s hodnotou permessage-deflate a zahrňte libovolné z kompresních parametrů definovaných v RFC-7692 ↗.

Provádět dodatečnou kontrolu chyb v rozhraní Web Crypto API v souladu se specifikací a odmítat potenciálně nebezpečné parametry klíčů:

• Při generování klíčů RSA musí být velikost klíče násobkem 128 bitů, jinak může boringssl klíč zkrátit.
• Velikost importovaných klíčů RSA musí být minimálně 256 bitů a maximálně 16384 bitů, stejně jako u nově vygenerovaných klíčů.
• Veřejný exponent pro importované klíče RSA je omezen na běžně používané hodnoty [3, 17, 37, 65537].
• V souladu se specifikací se při pokusu o import veřejného klíče ECDH s neprázdným seznamem usages vyvolá chyba.

Provádět dodatečnou kontrolu chyb v rozhraní Compression Streams API a vyvolat chybu, pokud DecompressionStream obsahuje koncová data navíc nebo se uzavře dříve, než jsou poskytnuta veškerá komprimovaná data.

Tento příznak mění chování mezipaměti při vyžádání assetů prostřednictvím Fetch API. Nastavení cache uvedená v request.cf objekt, jako například cacheEverything a cacheTtl, mají nyní přednost před jakýmkoli Cache Rules nastaveno.

Tento příznak zjednodušuje požadavky Workers tím, že omezuje zbytečné vlastnosti v request.cf objekt.

Když je příznak zapnutý, ať už ve výchozím stavu po 2023-08-01, nebo nastavením no_cf_botmanagement_default příznak, Cloudflare zahrne pouze Objekt Bot Management ve Workeru request.cf pokud má účet přístup k Bot Management.

Když je příznak vypnutý, Cloudflare zahrne výchozí objekt Bot Management bez ohledu na to, zda má účet k Bot Management nárok.

WHATWG zavedla další volitelné argumenty do URLSearchParams objekt delete() ↗ a has() ↗ metody, které umožňují přesnější kontrolu nad odstraňováním parametrů dotazu. Vzhledem k tomu, že argumenty jsou volitelné a mění chování metod, pokud jsou zadané, hrozí riziko narušení stávajícího kódu. Pokud máte datum kompatibility nastavené na 1. července 2023 nebo později, bude tento příznak kompatibility ve výchozím nastavení zapnutý.

Jako příklad toho, jak by tato změna mohla narušit stávající kód, uvažujme kód, který používá Array forEach() metoda pro procházení řady parametrů určených ke smazání:

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

forEach() automaticky předává funkci, která je zadána jako argument, více parametrů. Před přidáním nových standardních parametrů by tyto další argumenty byly ignorovány.

Nyní však mají doplňkové argumenty význam a mění chování funkce. S tímto příznakem by bylo nutné výše uvedený příklad upravit takto:

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

Změňte implementaci URL použitou v Response.redirect() aby vyhovoval specifikaci (WHATWG URL Standard).

Dříve při použití Workers for Platforms dynamic dispatch API pro odeslání HTTP požadavku uživatelskému Workeru. Pokud uživatelský Worker vyvolá výjimku, dynamic dispatch Worker obdrží HTTP 500 chybu bez těla. Když dynamic_dispatch_tunnel_exceptions příznak kompatibility je povolen, výjimka se místo toho propaguje zpět do Workeru dynamic dispatch. fetch() volání ve Workeru pro dynamic dispatch vyvolá stejnou výjimku. To odpovídá obdobnému chování service bindings a Durable Objects.

Přidá getSetCookie() ↗ metodu na Hlavičky ↗ API ve Workers.

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

Povoluje rozhraní Node.js API ve Workers Runtime. Pro data kompatibility 2026-08-04 nebo novější Workers povolí oba nodejs_compat a nodejs_compat_v2 ve výchozím nastavení.

Mějte na paměti, že některá rozhraní Node.js API jsou povolena pouze v případě, že datum kompatibility vašeho Workeru odpovídá některému z následujících dat nebo je pozdější:

Některé moduly Node.js jsou ve Workers dostupné pouze jako nefunkční stuby. Tyto moduly lze importovat nebo require, ale neposkytují funkční implementace odpovídajících Node.js API. Stuby existují kvůli kompatibilitě s balíčky, které kontrolují existenci modulu, a v kódu aplikace by se neměly používat přímo.

Následující stuby se automaticky povolí pouze v případě, že nodejs_compat je povoleno a datum kompatibility vašeho Workeru je na uvedeném datu nebo po něm:

Při povolování nodejs_compat, doporučujeme používat nejnovější verzi Wrangler CLI, a nejnovější datum kompatibility, aby byla kompatibilita co nejvyšší. Některé starší verze Wrangleru vkládají další polyfilly, které už nejsou potřeba, pokud Worker používá novější datum kompatibility, protože je v takovém případě poskytuje přímo runtime Workers.

Pro data kompatibility 2026-08-04 nebo novější, nodejs_compat a nodejs_compat_v2 se nepoužívají, protože stejné chování zajišťuje datum kompatibility. Stávající projekty tyto příznaky při aktualizaci data kompatibility odstraňovat nemusí. Chcete-li kompatibilitu s Node.js zcela vypnout, odstraňte kladné příznaky, pokud jsou přítomné. Poté přidejte oba no_nodejs_compat a no_nodejs_compat_v2.

Pokud se vám při použití určitého balíčku npm ve Workers zobrazují chyby, nejprve zkuste aktualizovat datum kompatibility a použít nejnovější verzi Wrangler CLI nebo Cloudflare Vite Plugin. Pokud potíže přetrvávají, nahlaste je prosím otevření issue na GitHubu ↗.

Přidá work-in-progress new ReadableStream() a new WritableStream() konstruktory podložené podkladovými zdroji (sources) a propady (sinks) v JavaScriptu.

Dříve new TransformStream() konstruktor neodpovídal standardu Streams API. Použijte transformstream_enable_standard_constructor abyste povolili zpětně nekompatibilní změnu, která zajistí soulad konstruktoru s požadavky. Musí se použít v kombinaci s streams_enable_constructors příznak.

Moduly CommonJS dříve exportovaly modulový jmenný prostor (objekt jako { default: module.exports }) místo toho, abyste exportovali jen module.exports. Pokud je tento flag povolený, export je pevně daný.

capture_async_api_throws příznak kompatibility zajistí, že v souladu se standardním API se asynchronní funkce odmítnou (reject) pouze tehdy, pokud vyvolají chybu. Opačný do_not_capture_async_api_throws příznak znamená, že asynchronní funkce obsahující chybu ji mohou vyhodit synchronně místo toho, aby ji odmítly (reject).

Původní implementace URL ↗ API ve Workers plně nevyhovovalo WHATWG URL Standard ↗, které se v několika ohledech liší, mimo jiné:

• Původní implementace sloučila posloupnosti více lomítek do jediného lomítka:

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

• Původní implementace by vyvolala "TypeError: Invalid URL string." pokud narazí na neplatné percent-encoded escape sekvence, jako https://example.com/a%%b.

• Původní implementace by u některého obsahu prováděla percent-encode nebo percent-decode jinak:

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

• Původní implementaci chybělo novější URL funkce, jako URL.canParse() ↗.

Nastavte datum kompatibility svého Workeru na datum po 2022-10-31 nebo povolte url_standard příznak kompatibility, kterým zapnete plně specifikaci odpovídající URL implementace API.

Viz response_redirect_url_standard příznak kompatibility , což ovlivňuje implementaci URL použitou v Response.redirect().

S r2_list_honor_include příznak nastaven, include argument do R2 list možnosti se respektuje. Se starším datem kompatibility a bez tohoto příznaku se include argument se implicitně chová jako include: ["httpMetadata", "customMetadata"].

V runtime byla chyba, kvůli které se neplatné hodnoty při předání do vestavěných API někdy chybně sloučily s null. Místo toho TypeError měla být vyvolána. dont_substitute_null_on_type_error opravuje toto chování tak, aby se za těchto okolností správně vyhodila chyba.

S minimal_subrequests příznak nastaven, fetch() subrequesty odeslané na endpointy ve vlastní zóně Workeru (takzvané subrequesty v rámci stejné zóny) mají omezenou sadu funkcí, které se na ně uplatňují. Tyto funkce se obecně na subrequesty v rámci stejné zóny neměly uplatňovat od začátku, takže se očekává jen velmi málo změn chování viditelných pro uživatele. Konkrétně mohou Workers s novým flagem pozorovat následující změny chování:

• Těla odpovědí nebudou před odesláním do runtime Workers oportunisticky komprimována pomocí gzip. Pokud Worker čte tělo odpovědi, přečte je v prostém textu, jak tomu bylo vždy, takže vypnutí této funkce zabraňuje zbytečné dekompresi. Pokud Worker naopak odpověď jen předává klientovi, oportunisticky zkomprimuje tělo odpovědi pomocí gzip až HTTP proxy Cloudflare, a to za runtime Workers. Změna chování, kterou skript Workeru může pozorovat, by měla spočívat v tom, že některé Content-Encoding: gzip hlavičky se už nebudou zobrazovat.
• Automatic Platform Optimization se dříve za určitých okolností mohla uplatnit jak na iniciační požadavek Workeru, tak na jeho podřízené požadavky. Nově se bude uplatňovat pouze na iniciační požadavek.
• Předběžné načítání odkazů (link prefetching) se nyní bude vztahovat pouze na odpověď Workeru, nikoli na odpovědi na dílčí požadavky Workeru.

S global_navigator příznak nastaven, nový globální navigator vlastnost dostupná i uvnitř Workers. Momentálně zpřístupňuje pouze jedinou navigator.userAgent vlastnost, jejíž hodnota je nastavena na 'Cloudflare-Workers'. Tuto vlastnost lze použít ke spolehlivému zjištění, zda kód běží v prostředí Workers.

no_cots_on_external_fetch příznak zakazuje použití Custom Origin Trust Store při odesílání externích (grey-clouded) subrequestů z Cloudflare Workeru.

Vlastnosti objektů Workers API byly původně definovány jako instanční vlastnosti, nikoli jako vlastnosti prototypu. To narušovalo dědění na úrovni JavaScriptu a bránilo podtřídám ve správném přepsání getterů/setterů nadřazené třídy. Tento flag řídí přelomovou změnu, která tyto gettery/settery nastavuje místo toho v šabloně prototypu.

Tato změna se vztahuje na:

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

Původně platilo, že při vytváření požadavku na Durable Object voláním stub.fetch(url), jako vstup byla přijata relativní URL adresa. URL adresa se interpretovala relativně vůči zástupné URL adrese http://fake-host, a výsledná absolutní adresa URL byla doručena do fetch() handler. Toto chování bylo chybné: plné adresy URL měly být povinné. Tento příznak plné adresy URL vyžaduje.

Původně, pokud fetch() funkci byla předána adresa URL určující jiný protokol než http: nebo https:, tiše by to zpracoval, jako by šlo o http:. Například fetch() by se mohlo zdát, že přijímá ftp: URL adresy, ale ve skutečnosti místo toho odesílal HTTP požadavky.

Mějte na paměti, že Cloudflare Workers podporuje nestandardní rozšíření fetch() aby podporoval WebSockets. Pokud ale odesíláte HTTP požadavek, který má zahájit handshake WebSocket, měli byste stále použít http: nebo https: jako protokol, nikoli ws: ani wss:.

ws: a wss: schémata URL jsou určena k použití společně s new WebSocket() konstruktor, který podporuje výhradně WebSocket. Rozšíření fetch() je navržena tak, aby podporovala HTTP i WebSocket v rámci stejného požadavku (odpověď může, ale nemusí zahájit WebSocket), a proto jsou všechny požadavky považovány za HTTP.

Runtime Workers původně neodpojoval ArrayBuffers z uživatelem poskytnutých TypedArrays při použití Čtečky BYOB read() metoda, jak vyžaduje specifikace Streams, což znamenalo, že bylo možné nechtěně znovu použít stejný buffer pro více read() volání. Tato změna přizpůsobuje Workers specifikaci.

Uživatelský kód by se nikdy neměl pokoušet znovu použít ArrayBuffer která byla předána do Čtečky BYOB read() metoda. Místo toho může uživatelský kód znovu použít ArrayBuffer která slouží jako podklad pro výsledek read() promise, jak je uvedeno v příkladu níže.

// 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);
}

Novější rozšiřující metoda readAtLeast() vždy odpojí ArrayBuffer a toto nastavení příznaku funkce ho neovlivňuje.

FormData API ↗ se používá k parsování dat (zejména těl HTTP požadavků) v multipart/form-data formát.

Původní implementace runtime Workers FormData API nesprávně převádělo nahrané soubory na řetězce. Proto formData.get("filename") by vrátilo řetězec s obsahem souboru místo File objekt. Tato změna problém řeší tím, že soubory jsou nyní reprezentovány pomocí File jak je uvedeno ve standardu.

Standard HTML5 definuje pevnou sadu prvků jako prázdné prvky (void elements), což znamená, že nepoužívají koncovou značku: <area>, <base>, <br>, <col>, <command>, <embed>, <hr>, <img>, <input>, <keygen>, <link>, <meta>, <param>, <source>, <track>, a <wbr>.

HTML5 nerozpoznává syntaxi samouzavíracích značek XML. Například <script src="foo.js" /> neurčuje element script bez těla. </script> koncová značka je stále vyžadována. /> syntax není v HTML5 vůbec rozpoznávána a zpracovává se stejně jako >. Mnoho vývojářů ale tuto syntaxi stále rádo používá, je to pozůstatek z XHTML, standardu, který se kolem roku 2000 neprosadil.

<esi:include> a <esi:comment> jsou dva tagy, které nejsou součástí standardu HTML5, ale používají se jako součást Edge Side Includes ↗, technologii pro úpravu HTML na straně serveru. Tyto značky by neměly obsahovat žádný obsah a obvykle se zapisují pomocí samostatně uzavírající syntaxe XML.

HTMLRewriter byl navržen pro parsování standardního HTML5, nikoli ESI. Bylo by však užitečné mít možnost implementovat některé části ESI pomocí HTMLRewriter. Za tímto účelem tento compatibility flag způsobí, že HTMLRewriter zacházet s <esi:include> a <esi:comment> jako void tagy, aby je bylo možné správně parsovat a zpracovat.

Tyto příznaky lze povolit prostřednictvím compatibility_flags, ale zatím není naplánováno, že by se k žádnému konkrétnímu datu staly výchozími.

Standardně Queues Consumer Workers potvrzují zprávy až poté, co se vyřeší promises předané do ctx.waitUntil() se vyřešily. Toto chování může u konzumentů front, kteří využívají ctx.waitUntil() pro pomalé zpracování zpráv. Výchozí chování je popsáno v Průvodce konfigurací Queues Consumer.

Tento Consumer Worker je příkladem Workeru, který využívá ctx.waitUntil(). Při výchozím chování tento consumer Worker potvrdí dávku zpráv až poté, co se dokončí funkce sleep.

export default {
  async fetch(request, env, ctx) {
    // omitted
  },

  async queue(batch, env, ctx) {
    console.log(`received batch of ${batch.messages.length} messages to queue ${batch.queue}`);
    for (let i = 0; i < batch.messages.length; ++i) {
      console.log(`message #${i}: ${JSON.stringify(batch.messages[i])}`);
    }
    ctx.waitUntil(sleep(30 * 1000));
  }
};

function sleep(ms) {
  return new Promise(resolve => setTimeout(resolve, ms));
}

Pokud queue_consumer_no_wait_for_wait_until příznak povolen, konzumenti Queues už nebudou čekat na promises předané do ctx.waitUntil() se vyřeší, než dojde k potvrzení zpráv. To může zlepšit výkon konzumentů front, kteří využívají ctx.waitUntil(). Pokud je flag povolený, consumer Worker ve výše uvedeném příkladu potvrdí dávku, aniž by čekal na dokončení funkce sleep.

Použití tohoto příznaku neovlivní chování ctx.waitUntil(). ctx.waitUntil() bude nadále prodlužovat dobu života vašeho konzumentského Workeru, aby mohl fungovat i poté, co byla dávka zpráv potvrzena.

Standard HTML5 definuje pevnou sadu prvků jako prázdné prvky (void elements), což znamená, že nepoužívají koncovou značku: <area>, <base>, <br>, <col>, <command>, <embed>, <hr>, <img>, <input>, <keygen>, <link>, <meta>, <param>, <source>, <track>, a <wbr>.

HTML5 nerozpoznává syntaxi samouzavíracích značek XML. Například <script src="foo.js" /> neurčuje element script bez těla. </script> koncová značka je stále vyžadována. /> syntax není v HTML5 vůbec rozpoznávána a zpracovává se stejně jako >. Mnoho vývojářů ale tuto syntaxi stále rádo používá, je to pozůstatek z XHTML, standardu, který se kolem roku 2000 neprosadil.

<esi:include> a <esi:comment> jsou dva tagy, které nejsou součástí standardu HTML5, ale používají se jako součást Edge Side Includes ↗, technologii pro úpravu HTML na straně serveru. Tyto značky by neměly obsahovat žádný obsah a obvykle se zapisují pomocí samostatně uzavírající syntaxe XML.

HTMLRewriter byl navržen pro parsování standardního HTML5, nikoli ESI. Bylo by však užitečné mít možnost implementovat některé části ESI pomocí HTMLRewriter. Za tímto účelem tento compatibility flag způsobí, že HTMLRewriter zacházet s <esi:include> a <esi:comment> jako void tagy, aby je bylo možné správně parsovat a zpracovat.