Allow Headers, Cookies & Query Params

Gothic serves your dynamic pages through a CDN (CloudFront on AWS), which caches them right at the edge. Which query params, cookies and headers land in the cache key — and get forwarded to your server — is controlled by the CDN field under Deploy.Providers.AWS in your gothic.config.go, using the Allow* builders.

By default (when you omit the CDN block entirely), all query params are part of the cache key — so ?lang=PT and ?lang=ENG render and cache separately — while no cookies and no headers are forwarded. Tune any of the three with the Allow* builders:

AWS: gothic.AWSProvider{
	// ...ServerMemory, ServerTimeout, Region, Profile, Stages...
	CDN: gothic.CDNConfig{
		QueryParams: gothic.AllowAll(),                          // default: all query params
		Cookies:     gothic.Allow("session"),                   // forward + vary on these cookies
		Headers:     gothic.Allow("CloudFront-Viewer-Country"), // whitelist only for headers
	},
},

There are four builders, and you never touch an enum or a struct directly:

• - gothic.AllowAll() — every value participates in the cache key and is forwarded.
• - gothic.AllowNone() — nothing is forwarded or cached on.
• - gothic.Allow("a", "b") — only this whitelist.
• - gothic.AllowAllExcept("utm_source") — everything except this list (not valid for Headers).

Important: Headers accept only AllowNone() or Allow(...) — CloudFront cache policies reject all/allExcept for headers. And never forward the Host or Authorization header for the server behavior: CloudFront signs the Lambda Function URL with SigV4 (via OAC) against the function URL's own host, so forwarding either one breaks the signature and returns HTTP 403.

The runtime assets cache themselves

Gothic's own client runtime — the files under /_gothic/, including the WASM core — is served with Cache-Control: public, max-age=31536000, immutable everywhere except GOTHIC_MODE=dev. A returning visitor re-downloads none of it.

That is safe because every one of those URLs carries a ?v= content hash. A new framework version produces a new hash, so it is a new URL that no browser has seen, and the old entry is simply never requested again. Nothing needs invalidating — which matters, because a CDN invalidation reaches the edge but never reaches a browser that already holds the file.

In dev the header is omitted on purpose: a rebuild replaces those files under the same name, so a cached copy would keep booting the previous runtime and break hot reload.

Now that your CDN caches exactly what you want, let's lock the door with a Web Application Firewall!