Clarify compatibility flags and DNS documentation

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:
 

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.

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.

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.

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.

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.
 

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/).

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.
 

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.                                                                                                                                                                   |

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).