Conversation
Rewrite introductions for clarity, fix typos (SNI, grammar), explain policy evaluation order, clarify TLS decryption and mTLS limitations, simplify AV scan criteria, fix outdated UI navigation paths, and add caution asides for HTTP/3 bypass behavior.
|
This pull request requires reviews from CODEOWNERS as it changes files that match the following patterns:
|
Oxyjun
changed the title
src/content/docs/cloudflare-one/traffic-policies/http-policies/common-policies.mdx
Show resolved
Hide resolved
| ### Application Controls | ||
|
|
||
| Application Controls are pre-defined controls which represent user intent, such as uploads or downloads. Cloudflare defines and organizes sets of operations deemed related to specific intents in an application. Application Controls represent the most commonly used controls. | ||
| Application Controls are pre-defined groups that represent common user actions, such as uploads or downloads. Cloudflare maps each Application Control to one or more underlying API operations for a given application. Use Application Controls when a pre-defined grouping matches your intent. |
There was a problem hiding this comment.
Good call. Revised to stay closer to the original terminology. Now says "pre-defined controls that represent user intent" (matching the original) instead of "pre-defined groups that represent common user actions." The second sentence now reads "Cloudflare organizes sets of related operations into Application Controls" — a restatement of the original meaning without adding unsourced claims about mapping mechanics. Fixed in c17e044.
| import { Details } from "~/components"; | ||
|
|
||
| Gateway supports inspection of HTTP/3 traffic, which uses the QUIC protocol over UDP. | ||
| HTTP/3 uses the QUIC protocol over UDP instead of TCP. Because Gateway's default proxy only handles TCP traffic, HTTP/3 inspection requires turning on the UDP proxy. Without it, HTTP/3 traffic bypasses Gateway inspection entirely. |
There was a problem hiding this comment.
Needs factcheck + source. Does it bypass Gateway entirely?
There was a problem hiding this comment.
You are right — "bypasses Gateway entirely" was imprecise. The proxy page says "HTTP/3 traffic will bypass inspection" — meaning HTTP inspection specifically, not all of Gateway. Network policies still apply to the underlying UDP traffic.
Revised to: "HTTP/3 traffic bypasses HTTP inspection. Network policies still apply to the underlying UDP traffic." Same correction applied to the caution aside. Fixed in c17e044.
| } from "~/components"; | ||
|
|
||
| Cloudflare Gateway can perform [SSL/TLS decryption](https://www.cloudflare.com/learning/security/what-is-https-inspection/) in order to inspect HTTPS traffic for malware and other security risks. | ||
| Cloudflare Gateway can perform [SSL/TLS decryption](https://www.cloudflare.com/learning/security/what-is-https-inspection/) to inspect HTTPS traffic for malware and other security risks. TLS decryption is required for HTTP policies to inspect encrypted traffic — without it, Gateway can only see the hostname (via SNI) but not the full URL, headers, or request body. |
There was a problem hiding this comment.
Need factcheck + source
There was a problem hiding this comment.
Source is the Do Not Inspect visibility limitation callout on the HTTP policies page: "Information contained within HTTPS encryption, such as the full requested URL, will not be visible if it bypasses Gateway inspection."
Revised wording to directly reference that source with a link rather than paraphrasing. Now reads: "Without it, information contained within HTTPS encryption, such as the full URL, headers, and request body, will not be visible to Gateway." Fixed in c17e044.
| When you turn on TLS decryption, Gateway will decrypt all traffic sent over HTTPS, apply your HTTP policies, and then re-encrypt the request with a [user-side certificate](/cloudflare-one/team-and-resources/devices/user-side-certificates/). | ||
|
|
||
| Cloudflare prevents traffic interference by decrypting, inspecting, and re-encrypting HTTPS requests in its data centers in memory only. Gateway only stores eligible cache content at rest. All cache disks are encrypted at rest. You can configure where TLS decryption takes place with [Regional Services](/data-localization/regional-services/) in the [Cloudflare Data Localization Suite (DLS)](/data-localization/). To further control what data centers traffic egresses from, you can use [dedicated egress IPs](/cloudflare-one/traffic-policies/egress-policies/dedicated-egress-ips/). | ||
| Gateway decrypts, inspects, and re-encrypts HTTPS requests in memory only within Cloudflare data centers. Gateway only stores eligible cache content at rest, and all cache disks are encrypted at rest. You can configure where TLS decryption takes place with [Regional Services](/data-localization/regional-services/) in the [Cloudflare Data Localization Suite (DLS)](/data-localization/). To further control what data centers traffic egresses from, you can use [dedicated egress IPs](/cloudflare-one/traffic-policies/egress-policies/dedicated-egress-ips/). |
There was a problem hiding this comment.
Need factcheck + source. Is this really talking about CF data centres?
There was a problem hiding this comment.
This paragraph was a rewrite of the original, which reads: "Cloudflare prevents traffic interference by decrypting, inspecting, and re-encrypting HTTPS requests in its data centers in memory only." My rewrite changed the subject from "Cloudflare" to "Gateway" and restructured the sentence, which altered the meaning.
Reverted to the original wording verbatim — this paragraph did not have a clarity issue that warranted rewriting. Fixed in c17e044.
Restore original wording for data center paragraph, clarify HTTP/3 bypasses HTTP inspection (not Gateway entirely), add source link for SNI visibility claim, restore Application Controls wording closer to original.
2 participants
Improves readability and reduces jargon across all 8 HTTP policies pages (
/cloudflare-one/traffic-policies/http-policies/), based on an ELI5 clarity analysis.index.mdx): Explain what HTTP policies do vs. network policies (Layer 7 vs. Layer 4), mention HTTP/3 support.index.mdx): Correct to "Server Name Indication" in Do Not Inspect section.index.mdx): Wrap in:::note— these policies always evaluate first regardless of list position.index.mdx): "togethers" → "together", add clarifying example.index.mdx): Remove mismatched trailing backslash-quote in Download/Upload Mime Type examples. Add clarifying sentence about MIME format.common-policies.mdx): Top-to-bottom first-match, except Do Not Inspect policies.filters: ["http"](common-policies.mdx): Note in API tab explaining Layer 7.common-policies.mdx): Explain why certificate-pinned apps reject Gateway's certificate.tls-decryption.mdx): Explain that without TLS decryption, Gateway can only see hostname (SNI), not full URL/headers/body.tls-decryption.mdx): Describe why Gateway cannot forward client certificates.tls-decryption.mdx): "Server Name Indicator" → "Server Name Indication". Explain why encrypted SNI breaks policy matching.antivirus-scanning.mdx): Convert dense paragraph to numbered list. Fix grammar in non-scannable files section.file-sandboxing.mdx): Fix "compare these a" → "compares them against". Clarify active voice in sandbox flow description.file-sandboxing.mdx,granular-controls.mdx,tenant-control.mdx): Remove outdated "Firewall policies" from navigation instructions.granular-controls.mdx): Rewrite Application Controls and Operations definitions for clarity.http3.mdx): Explain why HTTP/3 needs special handling (QUIC/UDP vs. TCP proxy). Add:::cautionfor non-Chrome HTTP/3 bypass.tenant-control.mdx): Explain the mechanism (header injection → SaaS reads header → rejects personal accounts) with a concrete example.