feat(deploy/site): serve the apex from the same Pages project, no redirect rule
Vercel was doing the apex->www 308 itself (its "redirect to www" project setting), so nothing about Cloudflare requires a redirect — the behaviour just disappears with Vercel. Rather than rebuild it with a zone Redirect Rule plus a proxied placeholder record, attach pcbjam.com as a SECOND custom domain on pcbjam-site. Both hosts serve the site and the pages already emit canonical=www, which is what consolidates them for search. That drops the riskiest artefact in the migration. Redirect Rules are zone-scoped and run BEFORE Workers/Pages routing, so a `contains` match instead of `eq` would 308 app./editor./demo./api. to www — breaking the product API, not just a marketing page. The sibling hosts are also the reason this was worth avoiding rather than merely guarding. APEX_MODE (lib/common.sh) selects the topology, defaulting to `serve`. 08-verify-prod.sh now dispatches through assert_apex: in serve mode it requires the apex to answer 200 with no hop, to not be a stale Vercel response, to declare canonical=www, and to expose /api/waitlist. The `redirect` mode and 07's rules/apex phases are kept for the alternative. 08 also checks the attached domains via wrangler rather than the REST API, so the whole serve-mode path needs only `wrangler login` — no zone scopes at all. Comments that explained themselves via the old redirect are corrected: astro.config.mjs, web/standalone/src/lib/config.ts and scripts/deploy/build-demo.mjs. The demo keeps posting to www — not because the apex redirects, but because a CORS preflight cannot follow one, so aiming at a host that might ever redirect is a latent breakage. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LAmkjM7okPdScp9XLW1JVr
This commit is contained in:
parent
04ce88f8a4
commit
df38ebafb7
7 changed files with 138 additions and 50 deletions
|
|
@ -64,8 +64,10 @@ export const APP_URL =
|
|||
* Where the in-editor waitlist form POSTs. The demo is a fully static deploy with
|
||||
* no backend, so it cross-posts to the landing site's serverless endpoint (which
|
||||
* sends CORS for this origin). Same JSON contract as site/src/pages/api/waitlist.ts.
|
||||
* Targets the canonical www host: the apex 308-redirects to www on Vercel, and a
|
||||
* CORS preflight can't follow a redirect (so the apex would break the POST).
|
||||
* Targets the canonical www host. The apex now serves the same Pages project
|
||||
* rather than redirecting, so either would work — but keep www: it is the
|
||||
* canonical host, and a CORS preflight cannot follow a redirect, so pointing at
|
||||
* a host that might ever redirect is a latent breakage.
|
||||
*/
|
||||
export const WAITLIST_URL =
|
||||
import.meta.env.VITE_WAITLIST_URL || "https://www.pcbjam.com/api/waitlist";
|
||||
|
|
|
|||
Loading…
Reference in a new issue