[Speed] Notes about the Content-Length header in responses

Author: pedrosousa

src/content/docs/speed/optimization/content/compression.mdx

@@ -151,11 +151,15 @@ If you do not want a particular response from your origin to be encoded with Bro
 Cloudflare will take into consideration the `accept-encoding` header value in website visitors' requests when sending responses to those visitors. However, when requesting content from your origin server, Cloudflare will send a different `Accept-Encoding` header, supporting Brotli and Gzip compression.
 :::
 
+### Content-Length header handling
+
+When Cloudflare compresses a response, it may omit the `Content-Length` HTTP header to avoid delivering incorrect length information caused by dynamic transformations. To preserve the `Content-Length` header, add `cache-control: no-transform` to the origin server's response. This directive prevents Cloudflare from altering compression on responses, allowing the `Content-Length` header to pass through as-is. The `cache-control: no-transform` header must be set by the origin — it cannot be added by client requests.
+
 ---
 
 <Render file="brotli-compression-warning" />
 
-## Compression methods by plan 
+## Compression methods by plan
 
 ### Between visitors and Cloudflare
 
@@ -167,4 +171,4 @@ By default, Cloudflare uses the following compression methods for content delive
 
 ### Between Cloudflare and the origin server
 
-On all plans, Cloudflare requests content from the origin server using the `accept-encoding: br, gzip` header. This means that Cloudflare asks the origin to send the content compressed using Brotli or Gzip, depending on which method the origin server supports.
+On all plans, Cloudflare requests content from the origin server using the `accept-encoding: br, gzip` header. This means that Cloudflare asks the origin to send the content compressed using Brotli or Gzip, depending on which method the origin server supports.

src/content/partials/speed/brotli-compression-warning.mdx

@@ -4,6 +4,8 @@
 
 ## Notes about end-to-end compression
 
+### Content recompression due to dynamic transformations
+
 Even when using the same compression algorithm end to end (between your origin server and Cloudflare, and between the Cloudflare global network and your website visitor), Cloudflare will need to decompress the response and compress it again if you enable any of the following settings for the request:
 
 - [Automatic HTTPS Rewrites](/ssl/edge-certificates/additional-options/automatic-https-rewrites/)
@@ -20,3 +22,7 @@ To disable these settings for specific URI paths, create a [configuration rule](
 :::note
 Additionally, the [Replace insecure JS libraries](/waf/tools/replace-insecure-js-libraries/) setting also requires Cloudflare to decompress the response and compress it again. At this time, you cannot turn it off using Configuration Rules.
 :::
+
+### Content-Length header
+
+Cloudflare may remove the `Content-Length` HTTP header of responses delivered to website visitors. To ensure that the header is preserved, add a `cache-control: no-transform` HTTP header to the response at the origin server.