Merge branch 'cloudflare:production' into production

Author: Thienlta

.github/workflows/issue-sync.yml

@@ -2298,7 +2298,8 @@
 /fundamentals/speed/amp-real-ulr/* /speed/optimization/other/amp-real-ulr/:splat 301
 /fundamentals/speed/rocket-loader/* /speed/optimization/content/rocket-loader/:splat 301
 /fundamentals/speed/signed-exchanges/* /speed/optimization/other/signed-exchanges/:splat 301
-/fundamentals/speed/speed-test/* /speed/speed-test/:splat 301
+/fundamentals/speed/speed-test/* /speed/observatory/:splat 301
+/speed/speed-test/* /speed/observatory/:splat 301
 /http-applications/* /version-management/:splat 301
 /http3/* https://www.cloudflare.com/learning/performance/what-is-http3/ 301
 /railgun/* / 301

public/__redirects

@@ -0,0 +1,19 @@
+---
+title: New Metrics View in AutoRAG
+description: Track file indexing, search activity, and top retrievals to understand how your AutoRAG instance is being used.
+products:
+  - autorag
+date: 2025-09-19
+---
+
+[AutoRAG](/autorag/) now includes a **Metrics** tab that shows how your data is indexed and searched. Get a clear view of the health of your indexing pipeline, compare usage between `ai-search` and `search`, and see which files are retrieved most often.  
+
+![Metrics](~/assets/images/autorag/metrics.png)
+
+You can find these metrics within each AutoRAG instance:
+
+- Indexing: Track how files are ingested and see status changes over time.
+- Search breakdown: Compare usage between `ai-search` and `search` endpoints.
+- Top file retrievals: Identify which files are most frequently retrieved in a given period.
+
+Try it today in [AutoRAG](/autorag/get-started/).

src/assets/images/autorag/metrics.png

@@ -12,7 +12,7 @@ This week’s vulnerability analysis highlights emerging web application threats
 
 - XSS – Attribute Overloading: A novel cross-site scripting technique where attackers abuse custom or non-standard HTML attributes to smuggle payloads into the DOM. These payloads evade traditional sanitization logic, especially in frameworks that loosely validate attributes or trust unknown tokens.
 - XSS – onToggle Event Abuse: Exploits the lesser-used onToggle event (triggered by elements like `<details>`) to execute arbitrary JavaScript when users interact with UI elements. This vector is often overlooked by static analyzers and can be embedded in seemingly benign components.
-- SQLi – Obfuscated Boolean Logic: An advanced SQL injection variant that uses non-standard Boolean expressions, comment-based obfuscation, or alternate encodings (for example, `/*!true*/`, `AND/**/1=1`) to bypass basic input validation and WAF signatures. This technique is particularly dangerous in dynamic query construction contexts.
+
 
 **Impact**
 
@@ -53,16 +53,5 @@ These vulnerabilities target both user-facing components and back-end databases,
 			<td>Block</td>
 			<td>This is a New Detection</td>
 		</tr>
-		<tr>
-			<td>Cloudflare Managed Ruleset</td>
-			<td>
-				<RuleID id="7663ea44178441a0b3205c145563445f" />
-			</td>
-			<td>100800</td>
-			<td>SQLi - Obfuscated Boolean</td>
-			<td>Log</td>
-			<td>Block</td>
-			<td>This is a New Detection</td>
-		</tr>
 	</tbody>
 </table>

src/content/changelog/autorag/2025-09-19-autorag-metrics.mdx

@@ -89,16 +89,5 @@ These vulnerabilities target user-facing components, web application servers, an
 			<td>Block</td>
 			<td>This is a New Detection</td>
 		</tr>
-			<tr>
-			<td>Cloudflare Managed Ruleset</td>
-			<td>
-				<RuleID id="9b5c5e13d2ca4253a89769f2194f7b2d" />
-			</td>
-			<td>100822</td>
-			<td>WordPress:Plugin:WPBookit - Remote Code Execution - CVE:CVE-2025-6058</td>
-			<td>Log</td>
-			<td>Block</td>
-			<td>This is a New Detection</td>
-		</tr>
 	</tbody>
 </table>

src/content/changelog/waf/2025-07-14-waf-release.mdx

@@ -0,0 +1,13 @@
+---
+title: Rate Limiting in Workers is now GA
+description: Workers Rate Limiting is now Generally Available
+products:
+  - workers
+date: 2025-09-19
+---
+ 
+[Rate Limiting within Cloudflare Workers](/workers/runtime-apis/bindings/rate-limit/) is now Generally Available (GA). 
+
+The `ratelimit` binding is now stable and recommended for all production workloads. Existing deployments using the unsafe binding will continue to function to allow for a smooth transition.
+
+For more details, refer to [Workers Rate Limiting](/workers/runtime-apis/bindings/rate-limit/) documentation.

src/content/changelog/waf/2025-07-28-waf-release.mdx

@@ -0,0 +1,60 @@
+---
+title: Panic Recovery for Rust Workers
+description: Deployments on workers-rs are now more reliable with automatic panic recovery
+date: 2025-09-19
+---
+
+import { WranglerConfig, Aside } from "~/components";
+
+In [workers-rs](https://github.com/cloudflare/workers-rs), Rust panics were previously non-recoverable. A panic would put the Worker into an invalid state, and further function calls could result in memory overflows or exceptions.
+
+Now, when a panic occurs, in-flight requests will throw 500 errors, but the Worker will automatically and instantly recover for future requests.
+
+This ensures more reliable deployments. Automatic panic recovery is enabled for all new workers-rs deployments as of version 0.6.5, with no configuration required.
+
+## Fixing Rust Panics with Wasm Bindgen
+
+Rust Workers are built with Wasm Bindgen, which treats panics as non-recoverable. After a panic, the entire Wasm application is considered to be in an invalid state.
+
+We now attach a default panic handler in Rust:
+
+```rust
+std::panic::set_hook(Box::new(move |panic_info| {
+  hook_impl(panic_info);
+}));
+```
+
+Which is registered by default in the JS initialization:
+
+```js
+import { setPanicHook } from "./index.js";
+setPanicHook(function (err) {
+	console.error("Panic handler!", err);
+});
+```
+
+When a panic occurs, we reset the Wasm state to revert the Wasm application to how it was when the application started.
+
+## Resetting VM State in Wasm Bindgen
+
+We worked upstream on the Wasm Bindgen project to implement a new [`--experimental-reset-state-function` compilation option](https://github.com/wasm-bindgen/wasm-bindgen/pull/4644) which outputs a new `__wbg_reset_state` function.
+
+This function clears all internal state related to the Wasm VM, and updates all function bindings in place to reference the new WebAssembly instance.
+
+One other necessary change here was associating Wasm-created JS objects with an instance identity. If a JS object created by an earlier instance is then passed into a new instance later on, a new "stale object" error is specially thrown when using this feature.
+
+## Layered Solution
+
+Building on this new Wasm Bindgen feature, layered with our new default panic handler, we also added a proxy wrapper to ensure all top-level exported class instantiations (such as for Rust Durable Objects) are tracked and fully reinitialized when resetting the Wasm instance. This was necessary because
+the workerd runtime will instantiate exported classes, which would then be associated with the Wasm instance.
+
+This approach now provides full panic recovery for Rust Workers on subsequent requests.
+
+Of course, we never want panics, but when they do happen they are isolated and can be investigated further from the error logs - avoiding broader service disruption.
+
+## WebAssembly Exception Handling
+
+In the future, full support for recoverable panics could be implemented without needing reinitialization at all, utilizing the [WebAssembly Exception Handling](https://github.com/WebAssembly/exception-handling/blob/main/proposals/exception-handling/Exceptions.md)
+proposal, part of the newly announced [WebAssembly 3.0](https://webassembly.org/news/2025-09-17-wasm-3.0/) specification. This would allow unwinding panics as normal JS errors, and concurrent requests would no longer fail.
+
+**We're making significant improvements to the reliability of [Rust Workers](https://github.com/cloudflare/workers-rs). Join us in `#rust-on-workers` on the [Cloudflare Developers Discord](https://discord.gg/cloudflaredev) to stay updated.**

src/content/changelog/workers/2025-09-19-ratelimit-workers-ga.mdx

@@ -26,7 +26,7 @@ If your website already has a `robots.txt` file — verified by a HTTP `200` res
 
 For example, without this feature enabled, the `robots.txt` content of `crawlstop.com` would be:
 
-```txt
+```txt title="Feature not enabled"
 User-agent: *
 Disallow: /lp
 Disallow: /feedback
@@ -37,16 +37,53 @@ Sitemap: https://www.crawlstop.com/sitemap.xml
 
 With the managed `robots.txt` enabled, Cloudflare will prepend our managed content before your original content, resulting in what you can view at https://www.crawlstop.com/robots.txt.
 
-**Robots.txt example**
-<div style="position: relative; padding-top: 56.25%; border: 1px solid orange; border-radius: 5px">
-<iframe
-	src="https://www.crawlstop.com/robots.txt"
-	style="border: none; position: absolute; top: 0; left: 0; height: 100%; width: 100%;"
-	allowfullscreen="true"
-	title="crawltop.com robots.txt file"
-	>
-</iframe>
-</div>
+```txt title="Feature enabled"
+# NOTICE: The collection of content and other data on this
+# site through automated means, including any device, tool,
+# or process designed to data mine or scrape content, is
+# prohibited except (1) for the purpose of search engine indexing or
+# artificial intelligence retrieval augmented generation or (2) with express
+# written permission from this site’s operator.
+
+# To request permission to license our intellectual
+# property and/or other materials, please contact this
+# site’s operator directly.
+
+# BEGIN Cloudflare Managed content
+
+User-agent: Amazonbot
+Disallow: /
+
+User-agent: Applebot-Extended
+Disallow: /
+
+User-agent: Bytespider
+Disallow: /
+
+User-agent: CCBot
+Disallow: /
+
+User-agent: ClaudeBot
+Disallow: /
+
+User-agent: Google-Extended
+Disallow: /
+
+User-agent: GPTBot
+Disallow: /
+
+User-agent: meta-externalagent
+Disallow: /
+
+# END Cloudflare Managed Content
+User-agent: *
+Disallow: /lp
+Disallow: /feedback
+Disallow: /langtest
+
+
+Sitemap: https://www.crawlstop.com/sitemap.xml
+```
 
 ### No robots.txt file
 

src/content/changelog/workers/2025-09-19-workers-rs-panic-recovery.mdx

@@ -28,7 +28,7 @@ warp-routing:
   enabled: true
 ```
 
-## File structure for public hostnames
+## File structure for published applications
 
 If you are exposing local services to the Internet, you can assign a public hostname to each service:
 
@@ -79,9 +79,9 @@ You can use wildcards to match traffic to multiple subdomains. For example, if y
 
 You can also enter regular expressions for the `path` key. For example, if `hostname` is `static.example.com` and `path` is `\.(jpg|png|css|js)$`, matching URLs could include `https://static.example.com/data.js`, `http://static.example.com/images/photo.jpg`, and so on. Cloudflare parses the path regex using the [Go `syntax` package](https://pkg.go.dev/regexp/syntax).
 
-### Supported protocols
+### Services
 
-In addition to HTTP, `cloudflared` supports protocols like SSH, RDP, arbitrary TCP services, and Unix sockets. You can also route traffic to the built-in `Hello World` test server or respond to traffic with an HTTP status.
+In addition to HTTP, `cloudflared` supports protocols like SSH, RDP, arbitrary TCP services, and Unix sockets. You can also route traffic to the built-in `hello_world` test server or respond to traffic with an HTTP status. For a full list of supported service types, refer to [Protocols for published applications](/cloudflare-one/connections/connect-networks/routing-to-tunnel/protocols/).
 
 ```yml
 tunnel: 6ff42ae2-765d-4adf-8112-31c55c1551ef
@@ -101,18 +101,6 @@ ingress:
   - service: http_status:404
 ```
 
-| Service                | Description                                                                                                                   | Example `service` value               |
-| ---------------------- | ----------------------------------------------------------------------------------------------------------------------------- | ------------------------------------- |
-| HTTP/S                 | Incoming HTTP requests are proxied directly to your local service.                                                            | `https://localhost:8000`              |
-| HTTP over Unix socket  | Just like HTTP, but using a Unix socket instead.                                                                              | `unix:/home/production/echo.sock`     |
-| HTTPS over Unix socket | Just like HTTPS, but using a Unix socket instead.                                                                             | `unix+tls:/home/production/echo.sock` |
-| TCP                    | TCP connections are proxied to your local service.                                                                            | `tcp://localhost:2222`                |
-| SSH                    | SSH connections are proxied to your local service. [Learn more](/cloudflare-one/connections/connect-networks/use-cases/ssh/). | `ssh://localhost:22`                  |
-| RDP                    | RDP connections are proxied to your local service. [Learn more](/cloudflare-one/connections/connect-networks/use-cases/rdp/). | `rdp://localhost:3389`                |
-| kubectl bastion mode   | `cloudflared` will act like a jumphost, allowing access to any local address.                                                 | `bastion`                             |
-| Hello World            | Test server for validating your Cloudflare Tunnel setup.                                                                      | `hello_world`                         |
-| HTTP status            | Responds to all requests with the given HTTP status.                                                                          | `http_status:404`                     |
-
 ### Origin configuration
 
 If you need to proxy traffic to multiple origins within one instance of `cloudflared`, you can define the way `cloudflared` sends requests to each service by specifying [configuration options](/cloudflare-one/connections/connect-networks/configure-tunnels/cloudflared-parameters/origin-parameters/) as part of your ingress rules.