diff --git a/src/content/compatibility-flags/allow-custom-ports.md b/src/content/compatibility-flags/allow-custom-ports.md index 3d71bc660bf3c4c..4a9cf4a9b5f6932 100644 --- a/src/content/compatibility-flags/allow-custom-ports.md +++ b/src/content/compatibility-flags/allow-custom-ports.md @@ -15,7 +15,7 @@ When this flag is enabled, and you specify a port when making a subrequest with When you make a subrequest to a website that uses Cloudflare ("Orange Clouded") — only [ports supported by Cloudflare's reverse proxy](/fundamentals/reference/network-ports/#network-ports-compatible-with-cloudflares-proxy) can be specified. If you attempt to specify an unsupported port, it will be ignored. -When you make a subrequest to a website that doesn't use Cloudflare ("Grey Clouded") - any port can be specified. +When you make a subrequest to a website that does not use Cloudflare ("Grey Clouded") - any port can be specified. For example: diff --git a/src/content/compatibility-flags/assets-navigation-prefers-asset-serving.md b/src/content/compatibility-flags/assets-navigation-prefers-asset-serving.md index ba62c5cd6d5ef43..ee022fe65a78ce2 100644 --- a/src/content/compatibility-flags/assets-navigation-prefers-asset-serving.md +++ b/src/content/compatibility-flags/assets-navigation-prefers-asset-serving.md @@ -13,6 +13,6 @@ disable_flag: "assets_navigation_has_no_effect" For Workers with [static assets](/workers/static-assets/) and this compatibility flag enabled, navigation requests (requests which have a `Sec-Fetch-Mode: navigate` header) will prefer to be served by our asset-serving logic, even when an exact asset match cannot be found. This is particularly useful for applications which operate in either [Single Page Application (SPA) mode](/workers/static-assets/routing/#not_found_handling--404-page--single-page-application--none) or [404 page mode](/workers/static-assets/routing/#not_found_handling--404-page--single-page-application--none), as this now means the fallback pages of `200 /index.html` and `404 /404.html` will be served ahead of invoking a Worker script and will therefore avoid incurring a charge. -Without this flag, the runtime will continue to apply the old behavior of invoking a Worker script (if present) for any requests which don't exactly match a static asset. +Without this flag, the runtime will continue to apply the old behavior of invoking a Worker script (if present) for any requests which do not exactly match a static asset. -This compatibility flag has no effect when `assets.run_worker_first = true` is set. `assets.run_worker_first = true` will continue to force the Worker script to execute ahead of all other asset-serving logic. +When `assets.run_worker_first = true` is set, this compatibility flag has no effect. The `assets.run_worker_first = true` setting ensures the Worker script executes before any asset-serving logic. diff --git a/src/content/compatibility-flags/durable-object-stub-fetch-requires-a-full-url.md b/src/content/compatibility-flags/durable-object-stub-fetch-requires-a-full-url.md index 832c0f3c3d96b22..18e3c4215e0ce73 100644 --- a/src/content/compatibility-flags/durable-object-stub-fetch-requires-a-full-url.md +++ b/src/content/compatibility-flags/durable-object-stub-fetch-requires-a-full-url.md @@ -11,4 +11,4 @@ enable_flag: "durable_object_fetch_requires_full_url" disable_flag: "durable_object_fetch_allows_relative_url" --- -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. +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 placeholder URL `http://fake-host`, and the resulting absolute URL was delivered to the destination object's `fetch()` handler. This behavior was incorrect — full URLs were meant to be required. This flag makes full URLs required. diff --git a/src/content/compatibility-flags/nodejs-als.md b/src/content/compatibility-flags/nodejs-als.md index 6943fb294f49bf6..45c66bc51476217 100644 --- a/src/content/compatibility-flags/nodejs-als.md +++ b/src/content/compatibility-flags/nodejs-als.md @@ -10,4 +10,4 @@ enable_flag: "nodejs_als" disable_flag: "no_nodejs_als" --- -Enables the availability of the Node.js [AsyncLocalStorage](https://nodejs.org/api/async_hooks.html#async_hooks_class_asynclocalstorage) API in Workers. This API allows you to store data that is accessible to all asynchronous operations within a given execution context. This is useful for storing data that is relevant to the current request, such as request-specific metadata or tracing information. +Enables the availability of the Node.js [AsyncLocalStorage](https://nodejs.org/api/async_hooks.html#async_hooks_class_asynclocalstorage) API in Workers. diff --git a/src/content/compatibility-flags/rpc.md b/src/content/compatibility-flags/rpc.md index a8146733bd403d2..2768e89233a42e7 100644 --- a/src/content/compatibility-flags/rpc.md +++ b/src/content/compatibility-flags/rpc.md @@ -13,4 +13,4 @@ disable_flag: "no_rpc" With this flag on, [Durable Object](/durable-objects/) stubs and [Service Bindings](/workers/runtime-apis/bindings/service-bindings/) support [RPC](/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's 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've seen code in the wild which iterates over [bindings](/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've seen, the impact was benign (nothing actually broke), but out of caution we are guarding this change behind a flag. +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](/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. diff --git a/src/content/compatibility-flags/upper-case-http-methods.md b/src/content/compatibility-flags/upper-case-http-methods.md index 5f7a53001ff61f8..3f1b1e2862cc24f 100644 --- a/src/content/compatibility-flags/upper-case-http-methods.md +++ b/src/content/compatibility-flags/upper-case-http-methods.md @@ -14,9 +14,9 @@ disable_flag: "no_upper_case_all_http_methods" HTTP methods are expected to be upper-cased. Per the fetch spec, if the method is specified as `get`, `post`, `put`, `delete`, `head`, or `options`, implementations are expected to uppercase the method. All other method names -would generally be expected to throw as unrecognized (e.g. `patch` would be -an error while `PATCH` is accepted). This is a bit restrictive, even if it -is in the spec. This flag modifies the behavior to uppercase all methods +would generally be expected to throw as unrecognized (for example, `patch` would be +an error while `PATCH` is accepted). This is a bit restrictive, even if it is in the spec. +This flag modifies the behavior to uppercase all methods prior to parsing so that the method is always recognized if it is a known method. diff --git a/src/content/docs/1.1.1.1/encryption/dns-over-https/dns-over-https-client.mdx b/src/content/docs/1.1.1.1/encryption/dns-over-https/dns-over-https-client.mdx index 8d17e6df525d8fb..c4899e12dddc2db 100644 --- a/src/content/docs/1.1.1.1/encryption/dns-over-https/dns-over-https-client.mdx +++ b/src/content/docs/1.1.1.1/encryption/dns-over-https/dns-over-https-client.mdx @@ -5,7 +5,8 @@ slug: 1.1.1.1/encryption/dns-over-https/dns-over-https-client description: Learn how to connect to Cloudflare's 1.1.1.1 using DNS over HTTPS (DoH) clients. --- -There are several DoH clients you can use to connect to 1.1.1.1. +Several DoH clients are available for connecting to 1.1.1.1. + ## cloudflared 1. [Download and install the `cloudflared` daemon](/cloudflare-one/connections/connect-networks/downloads/). diff --git a/src/content/docs/1.1.1.1/encryption/dns-over-https/encrypted-dns-browsers.mdx b/src/content/docs/1.1.1.1/encryption/dns-over-https/encrypted-dns-browsers.mdx index 997a4a64feff1be..30fc252e6eccf8f 100644 --- a/src/content/docs/1.1.1.1/encryption/dns-over-https/encrypted-dns-browsers.mdx +++ b/src/content/docs/1.1.1.1/encryption/dns-over-https/encrypted-dns-browsers.mdx @@ -5,7 +5,7 @@ slug: 1.1.1.1/encryption/dns-over-https/encrypted-dns-browsers --- -There are several browsers compatible with DNS over HTTPS (DoH). This protocol lets you encrypt your connection to 1.1.1.1 in order to protect your DNS queries from privacy intrusions and tampering. +Several browsers support DNS over HTTPS (DoH), a protocol that encrypts your connection to 1.1.1.1 to protect your DNS queries from privacy intrusions and tampering. Some browsers might already have this setting enabled. diff --git a/src/content/docs/1.1.1.1/encryption/dns-over-https/make-api-requests/dns-json.mdx b/src/content/docs/1.1.1.1/encryption/dns-over-https/make-api-requests/dns-json.mdx index 07427616a63f596..b8105fa7fb448c0 100644 --- a/src/content/docs/1.1.1.1/encryption/dns-over-https/make-api-requests/dns-json.mdx +++ b/src/content/docs/1.1.1.1/encryption/dns-over-https/make-api-requests/dns-json.mdx @@ -76,8 +76,8 @@ The following tables have more information on each response field. | Field | Description | | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `Status` | The Response Code of the DNS Query. These are defined here: [https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6](https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6). | -| `TC` | If true, it means the truncated bit was set. This happens when the DNS answer is larger than a single UDP or TCP packet. TC will almost always be false with Cloudflare DNS over HTTPS because Cloudflare supports the maximum response size. | +| `Status` | The Response Code of the DNS Query. The codes are defined here: [https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6](https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6). | +| `TC` | If the `TC` field is true, the truncated bit was set. This occurs when the DNS answer exceeds the size of a single UDP or TCP packet. With Cloudflare DNS over HTTPS, the `TC` field is almost always false because Cloudflare supports the maximum response size. | | `RD` | If true, it means the Recursive Desired bit was set. This is always set to true for Cloudflare DNS over HTTPS. | | `RA` | If true, it means the Recursion Available bit was set. This is always set to true for Cloudflare DNS over HTTPS. | | `AD` | If true, it means that every record in the answer was verified with DNSSEC. | diff --git a/src/content/docs/1.1.1.1/encryption/dns-over-https/make-api-requests/index.mdx b/src/content/docs/1.1.1.1/encryption/dns-over-https/make-api-requests/index.mdx index c58963a2fbbe375..cf89ce8a39ca79d 100644 --- a/src/content/docs/1.1.1.1/encryption/dns-over-https/make-api-requests/index.mdx +++ b/src/content/docs/1.1.1.1/encryption/dns-over-https/make-api-requests/index.mdx @@ -31,7 +31,7 @@ Refer to [DNS wireformat](/1.1.1.1/encryption/dns-over-https/make-api-requests/d ## Send multiple questions in a query -Sending more than one question when making requests depends on the HTTP version used, as each DNS query maps to exactly one HTTP request. HTTP/2 and HTTP/3 have multiplexing, and you can start multiple requests concurrently. HTTP/2 is, in fact, the minimum recommended version of HTTP for use with DNS over HTTPS (DoH). This is not specific to 1.1.1.1, but rather how DoH works. +Sending more than one question when making requests depends on the HTTP version used, as each DNS query maps to exactly one HTTP request. HTTP/2 and HTTP/3 have multiplexing capabilities, allowing multiple requests to start concurrently. HTTP/2 is, in fact, the minimum recommended version of HTTP for use with DNS over HTTPS (DoH). This behavior is not specific to 1.1.1.1, but rather how DoH operates. You can learn more about how DoH works in RFC 8484, more specifically [the HTTP layer requirements](https://datatracker.ietf.org/doc/html/rfc8484#section-5.2).