preview-cloudflare: a preview never returns 404, since Cloudflare Pages serves index.html for unknown paths

Open Beginner friendly
  • Is something wrong?
#291 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
78/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
github-actions, shell
Domain
ci-cd, devops

Research direction

Start by reading the preview-cloudflare action and its harness, then trace where the build directory is prepared before upload. Check that a minimal top-level 404.html is created only when one is absent. Done when the harness covers both cases and a staged Pages preview returns 404 for unknown paths.

Written by the indexing model from the issue text.

Description

low-priority

A Cloudflare Pages preview never answers 404. When a deployment has no top-level 404.html, Cloudflare Pages treats the site as a single-page application and serves the root index.html, with a 200, for every path it doesn't hold. A Jupyter Book build makes no 404.html, and its root index.html is a redirect to the first page. So on a preview-cloudflare preview, a removed page, a removed notebook or a mistyped link lands on the book's first page instead of a 404.

v0.17.0's staged release showed it (QuantEcon/test-actions-lecture-intro#82, push 2, run 42748536799). The push deleted linear_equations and _static/qe-logo-large.png.

  • The Netlify preview returned 404 for the page, for _notebooks/linear_equations.ipynb and for the file, and 200 for the controls.
  • The Cloudflare preview's per-deployment URL returned 200 for all three, and for a made-up path. Each served the same 58-byte root index.html, <meta http-equiv="Refresh" content="0; url=intro.html" />.

The deleted content itself was gone, so the release was fine. But a reviewer following a broken link on a Cloudflare preview doesn't see that it's broken.

A possible fix: before the upload, preview-cloudflare writes a minimal 404.html into the deploy directory when the build has none. With a top-level 404.html, Cloudflare Pages serves it with a 404 status for unknown paths. A build that already has one keeps it. The harness can check the file is written, and left alone when present; a staged release can check the status codes.

deploy-cloudflare deploys to Workers static assets, whose default not-found handling is a plain 404, so this looks specific to Pages. Confirm that for #145's preview-workers when it is built.

Low priority: previews are mostly read for the pages a pull request changes.

Claude Code (on behalf of mmcky), organiser session

Dominant language
Shell
Stars
0
Forks
1
Avg merge
20h 3m
Merged PRs (30d)
48

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from QuantEcon/actions

All issues in QuantEcon/actions

Similar issues

More Shell/Bash issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.