Added docs for cache: no-store

Author: tewaro

src/content/compatibility-dates/cache-no-store.md

@@ -0,0 +1,31 @@
+---
+_build:
+	publishResources: false
+	render: never
+	list: never
+
+name: "Enable `cache: no-store` HTTP standard API"
+sort_date: "2024-11-11"
+enabled_date: "2024-11-11"
+enable_flag: "cache_option_enabled"
+disable_flag: "cache_option_disabled"
+---
+
+When this flag is enabled, the cache header becomes available within the [`fetch()` API](/workers/runtime-apis/fetch/). The option for `no-store` is enabled.
+
+For a cross-zone request this simply specifies the headers `Pragma: no-cache` and `Cache-Control: no-cache` to the origin.
+
+For grey-cloud subrequests this bypasses the cloudflare's cache.
+
+Example:
+
+```js
+const response = await fetch("https://example.com", { cache: 'no-store'});
+```
+
+You can also create a Response object to pass around:
+
+```js
+const request = new Response("https://example.com", { cache: 'no-store'});
+const response = await fetch(request);
+```

src/content/docs/workers/examples/cache-using-fetch.mdx

@@ -466,3 +466,15 @@ async function handleRequest(request) {
 ```
 
 </TabItem> </Tabs>
+
+## Using the HTTP Cache API
+
+Currently we only support the `no-store` header for controlling cache.
+When `no-store` is supplied the cache is bypassed both on the way to the origin and on the way back.
+For cross-zone requests this simply forwards the `Pragma: no-cache` and `Cache-Control: no-cache` headers to the origin.
+This is because the cache is on the origin side for cross-zone requests.
+For grey-cloud requests this bypasses the use of Cloudflare's caches.
+
+```js
+fetch(event.request, { cache: 'no-store'});
+```

src/content/docs/workers/runtime-apis/request.mdx

@@ -62,7 +62,9 @@ let request = new Request(input, options)
 
 An object containing properties that you want to apply to the request.
 
+* `cache` `undefined | 'no-store'` optional
 
+	* Standard HTTP `cache` header. Only `cache: no-store` is supported.
 
 * `cf` RequestInitCfProperties optional
 
@@ -180,7 +182,7 @@ All properties of an incoming `Request` object (the request you receive from the
 
   :::caution
 
-  If the response is a redirect and the redirect mode is set to `follow` (see below), then all headers will be forwarded to the redirect destination, even if the destination is a different hostname or domain. This includes sensitive headers like `Cookie`, `Authorization`, or any application-specific headers. If this is not the behavior you want, you should set redirect mode to `manual` and implement your own redirect policy. Note that redirect mode defaults to `manual` for requests that originated from the Worker's client, so this warning only applies to `fetch()`es made by a Worker that are not proxying the original request. 
+  If the response is a redirect and the redirect mode is set to `follow` (see below), then all headers will be forwarded to the redirect destination, even if the destination is a different hostname or domain. This includes sensitive headers like `Cookie`, `Authorization`, or any application-specific headers. If this is not the behavior you want, you should set redirect mode to `manual` and implement your own redirect policy. Note that redirect mode defaults to `manual` for requests that originated from the Worker's client, so this warning only applies to `fetch()`es made by a Worker that are not proxying the original request.
   :::
 
 * `method` string read-only
@@ -410,4 +412,4 @@ Using any other type of `ReadableStream` as the body of a request will result in
 * [Examples: Modify request property](/workers/examples/modify-request-property/)
 * [Examples: Accessing the `cf` object](/workers/examples/accessing-the-cloudflare-object/)
 * [Reference: `Response`](/workers/runtime-apis/response/)
-* Write your Worker code in [ES modules syntax](/workers/reference/migrate-to-module-workers/) for an optimized experience.
+* Write your Worker code in [ES modules syntax](/workers/reference/migrate-to-module-workers/) for an optimized experience.