void 0.21.9 → 0.23.0

package/skills/void/docs/guide/edge/prerendering.md

@@ -4,7 +4,7 @@ outline: deep
 
 # Edge Prerendering
 
-You can instruct Void to prerender a page so it is served from cache immediately after a new deploy. Prerendering happens on the platform at deploy time. The platform invokes the uploaded worker and writes the result to the edge cache.
+Prerender pages at deploy time so the first visitor receives cached HTML.
 
 - [Markdown pages](../pages-routing/markdown.md) are auto-prerendered.
 - [Island pages](../pages-routing/islands) with no companion loader and no dynamic params are also auto-prerendered.
@@ -16,13 +16,9 @@ Export `prerender = true` from the companion `.server.ts` file:
 ```ts
 // pages/about.server.ts
 export const prerender = true;
-
-export const loader = defineHandler(async (c) => {
-  // ...
-});
 ```
 
-Pages with no dynamic params are automatically prerendered at their URL pattern (e.g. `/about`).
+Pages without dynamic params do not need `getPrerenderPaths()`.
 
 ## Dynamic pages (with params)
 
@@ -36,10 +32,6 @@ export async function getPrerenderPaths() {
   // Return param objects matching the URL pattern
   return [{ slug: 'hello-world' }, { slug: 'getting-started' }];
 }
-
-export const loader = defineHandler(async (c) => {
-  // ...
-});
 ```
 
 ## Custom SSR
@@ -53,21 +45,15 @@ export const prerender = true;
 export async function getPrerenderPaths() {
   return ['/', '/about', '/blog/hello-world'];
 }
-
-export default defineRender(async (c, assetTags) => {
-  // ...
-});
 ```
 
 ## Relationship to revalidation
 
 Setting `routing.isr: false` in `void.config.ts` disables ISR and this edge-prerendering behavior, including per-page exports. It does not disable build-time HTML generation with `output: "static"`.
 
-Pages with long revalidate TTLs (e.g. 1 year) are effectively static, but the first visitor after a deploy hits a cold cache. This is where prerendering helps - it ensures your users never get slow requests.
-
-Enabling prerendering for a page automatically sets `revalidate` to 1 year, so you don't need to export it yourself. Since the ISR cache is cleared on every deploy, the TTL only needs to be long enough to last between deploys.
+Prerendered pages default to a one-year revalidate TTL. Deploys clear the ISR cache.
 
-You can also explicitly set to it a different value to override the default:
+Override the TTL per page:
 
 ```ts
 // pages/about.server.ts
@@ -75,11 +61,10 @@ export const prerender = true;
 export const revalidate = 3600;
 ```
 
-Just be aware that if no new deploy happens before the revalidate expires, the first user request after expiration will miss the cache and incur a full render.
+If the cached page expires before your next deploy, the next request waits for a fresh render.
 
 ## Behavior details
 
 - Prerender happens once per deployment, before traffic is routed to the new version. Prerendered pages are cached at the edge.
-- Each deploy clears the ISR cache. The deployment shows `"prerendering"` during this phase.
 - Only paths with a positive revalidate TTL are prerendered (TTL `0` is skipped).
 - Prerender failures are logged but never block the deploy. The page will render on the first request as usual.

package/skills/void/docs/guide/edge/redirects.md

@@ -23,42 +23,12 @@ Define URL redirects in [`void.config.ts`](../../reference/config) using the `ro
 - **Destinations** can be strings (default `302`) or objects with `to` and optional `status`. Supported statuses: `301`, `302`, `303`, `307`, `308`.
 - `:splat` in the destination is replaced with the portion of the path matched by `*` in the source pattern.
 - Destination query strings are merged into the `Location` header (the destination's parameters take precedence on per-key conflict). To drop the incoming query, write an explicit reset like `?`.
-- When multiple rules match, the **first match wins**. Put more-specific rules above more-general ones (matches Netlify `_redirects` and Vercel `vercel.json` semantics).
+- When multiple rules match, the **first match wins**. Put specific patterns before catch-all patterns.
 - Redirects are evaluated **before** the request reaches the worker, so they short-circuit static asset serving, ISR, and SSR.
 
-## Example: permanent redirect
-
-```json
-{
-  "routing": {
-    "redirects": {
-      "/old-page": { "to": "/new-page", "status": 301 }
-    }
-  }
-}
-```
-
-## Example: path prefix migration
-
-```json
-{
-  "routing": {
-    "redirects": {
-      "/blog/*": { "to": "/posts/:splat", "status": 301 }
-    }
-  }
-}
-```
-
-A request to `/blog/hello-world` redirects to `/posts/hello-world` with a `301` status.
-
 ## Domain-level redirects
 
-Scope a redirect to a specific Host header by prefixing the source with `https://host`. Useful for:
-
-- **Domain consolidation** — redirect everything from an old marketing domain to a new one without per-host deploy config.
-- **Canonical host enforcement** — `www.example.com` → `example.com`.
-- **Per-domain rules on a multi-domain project** — when you've bound several custom domains to one project but want different behavior on each.
+Prefix a source with `https://host` to redirect only requests to that domain:
 
 ```json
 {
@@ -74,43 +44,20 @@ Scope a redirect to a specific Host header by prefixing the source with `https:/
 The `_redirects` file accepts the same syntax:
 
 ```
-https://www.example.com/*  https://example.com/:splat  301!
+https://www.example.com/*  https://example.com/:splat  301
 ```
 
-The host portion is split off the source and stored as a `host` field on the rule. Path-only sources (no `https://` prefix) apply to every domain bound to the project — that's the existing behavior. Host-prefixed sources only fire when the request's `Host` header matches.
-
-### Validation
-
-- The host must be a literal hostname — wildcards (`*.example.com`), ports, paths, and userinfo are rejected.
-- Only `https://` is accepted. `http://` and protocol-relative `//` sources are rejected — TLS terminates upstream of the worker, so an `http://`-scoped rule physically cannot fire.
-- The host must be **bound to your project** (either `<slug>.void.app` or a custom domain you've added via `void domain add`). `void deploy` rejects rules scoped to hosts that aren't on the project — staging the rule in the same change as the domain is the recommended flow.
-- Custom domains in `pending` (DCV-in-progress) state are accepted. The rule deploys but stays inert until DCV completes; once the certificate is issued, the rule starts firing automatically without a redeploy.
-
-### Combined with external destinations
+Path-only sources apply to every domain on the project. Host-prefixed sources apply only to the named domain.
 
-The source `host` and the destination URL are independent. Combining them lets you express domain-consolidation redirects in a single rule:
-
-```
-https://old.example.com/*  https://www.example.com/:splat  301!
-```
-
-Reads as "when a request hits `old.example.com` on any path, send a 301 to the same path on `www.example.com`."
+The source must use `https://` and a literal hostname without wildcards or a port. Add the domain to your project with `void domain add` before deploying the rule. A domain awaiting certificate verification starts redirecting once it becomes active.
 
 ## Framework `_redirects` files
 
-Meta-frameworks may generate a `_redirects` file during build. Void parses this file at deploy time and merges the rules into the deploy manifest.
+Void reads `_redirects` files produced by supported frameworks. You can also place one in Vite's `publicDir`:
 
-- `void.config.ts` rules are applied **before** framework-generated `_redirects` rules. Since the first match wins, `routing.redirects` in `void.config.ts` takes precedence.
-- Both 3xx redirect rules and status `200` [rewrite rules](./rewrites) are supported in `_redirects` files.
-- The `!` force suffix is only meaningful on `200` entries (see [rewrites — `_redirects` file](./rewrites#redirects-file)). On 3xx entries (`301!`, `302!`, `307!`, `308!`) it's silently stripped — a redirect always "forces" by nature, so the suffix is redundant. `void deploy` prints a single aggregated warning tallying every such entry so you can clean them up.
-- The `_redirects` file is not uploaded as a static asset. Its contents are parsed and included in the manifest only.
-
-Precedence when the same source appears in both sources follows the same rules as rewrites — config rules are merged before file rules within each phase, and first match wins, so `void.config.ts` overrides `_redirects`. See [rewrite precedence](./rewrites.md) for a worked example.
-
-## How redirects work
-
-1. `void deploy` reads redirect rules from the framework `_redirects` file (if present) and `routing.redirects` in `void.config.ts`, then includes them in the deploy manifest.
-2. The platform stores the rules in the KV routing entry for your project.
-3. The dispatch worker checks redirect rules before any worker invocation, so matching requests get a redirect response immediately.
+```text
+/old-page  /new-page     301
+/blog/*    /posts/:splat 301
+```
 
-Because rules are evaluated at the edge before invoking the worker, redirects add no latency to the request path.
+Rules in `void.config.ts` take precedence over file rules. Use `200` for a fallback or `200!` for a [rewrite](./rewrites#redirects-file). Redirects don't need the `!` suffix.

package/skills/void/docs/guide/edge/revalidation.md

@@ -74,13 +74,9 @@ When multiple sources set a revalidate TTL, the most specific wins:
 
 ## How revalidation works
 
-1. **First request:** there is no cache entry yet. The worker renders the page, returns the response, and writes the result to KV in the background.
+The first request renders and caches the page. While the cached page is fresh, visitors receive it immediately. Once it becomes stale, Void serves it while rendering an updated version in the background.
 
-2. **Subsequent requests (fresh):** the cached response is served from the edge cache or KV. No worker call is needed.
-
-3. **Subsequent requests (stale):** the stale cached response is served immediately, and the worker re-renders in the background. The next request gets the fresh version.
-
-While a stale entry is available, visitors can receive it without waiting for the refresh. A request without a cached entry still needs to render the page.
+A request without a cached entry waits for the page to render.
 
 ## Per-response TTL override
 
@@ -100,12 +96,13 @@ export const GET = defineHandler(async (c) => {
 
 Only complete `200` responses are cached. A response with `Cache-Control: private`,
 `no-store`, or `no-cache`, or any `Set-Cookie` header, stays private to that request.
-If a previously public page starts returning one of those headers during background
-revalidation, Void removes its HTML, Pages JSON, and KV cache entries.
+If a public page starts returning one of those headers, Void removes its cached response.
+
+Responses that vary by request headers, such as `Vary: Accept-Language` or `Vary: Origin`, are rendered live. `Vary: *` also disables shared caching. Void's `X-VoidPages` header is supported because HTML and Pages JSON have separate cached responses.
 
 ## Cache bypass
 
-Requests with `Cookie` or `Authorization` headers bypass the ISR cache entirely and always dispatch to the worker. This ensures personalized or authenticated pages are never served from a shared cache.
+Requests with `Cookie`, `Authorization`, or Cloudflare Access's `Cf-Access-Jwt-Assertion` header bypass the ISR cache entirely and always dispatch to the worker. Authenticated responses are not shared between users, including when Access authentication supplies no cookie.
 
 ## Cache keys and rewrites
 
@@ -115,16 +112,6 @@ Query parameters are excluded by default. Add `routing.revalidateQueryAllowlist`
 
 Purge the destination pathname with `revalidate({ paths })`. Purging `/en/docs/foo` clears both direct and rewritten variants. Purging only `/docs/foo` won't clear them, because the entries are stored under the destination.
 
-::: details Upgrading from the older ISR cache format
-
-The current format uses a `v3` host-scoped prefix and a cache-policy version in its
-metadata. Entries written before the current response-privacy policy are treated as
-cold misses and refill only from responses that are safe to share.
-
-Adding a rewrite also changes the affected page's cache key, so that page starts with a cold cache again.
-
-:::
-
 ## On-demand revalidation
 
 You can purge ISR cache entries programmatically from a route handler: