Intermittent RFC 8621 canonical info URL self-redirects repeatedly with 301 #577

Observed behavior

On 2026-10-29, our GitHub-hosted link-checking job observed a repeated 301 self-redirect at https://www.rfc-editor.org/info/rfc8621/, reached from https://www.rfc-editor.org/rfc/rfc8621. This was intermittent: the preceding run passed, and a later local GET eventually returned 200. The report identifies an observed production redirect chain, not a proven defect in a particular deployed component.

Failing run: https://github.com/link-foundation/meta-sovereign/actions/runs/40827010880 (started 06:04:19 UTC). The executed lychee output at 06:09:47 UTC says:

[502] https://www.rfc-editor.org/rfc/rfc8621
Followed 11 redirects:
https://www.rfc-editor.org/rfc/rfc8621 --[301]-->
https://www.rfc-editor.org/info/rfc8621/ --[301]-->
https://www.rfc-editor.org/info/rfc8621/ --[301]--> ...

Three further references to the same URL timed out at 06:10:48–06:11:48 after 13, 14 and 15 redirects, all to the identical /info/rfc8621/ URL. Our four translated email documentation pages reference this RFC. The checker correctly failed; successful Wayback lookup did not override the failure.

Bounded reproduction / collecting more evidence

During an affected period, run each request once and retain the header chain:

curl --location --max-redirs 5 --dump-header rfc8621-legacy.headers \
  --output rfc8621-legacy.html --write-out '%{http_code} %{url_effective}\n' \
  https://www.rfc-editor.org/rfc/rfc8621
curl --location --max-redirs 5 --dump-header rfc8621-info.headers \
  --output rfc8621-info.html --write-out '%{http_code} %{url_effective}\n' \
  https://www.rfc-editor.org/info/rfc8621/

Expected: a finite canonicalization chain followed by 200; never Location equal to the current URL. Actual CI observation: repeated same-URL 301, then 502/timeouts. The local legacy probe started at 06:14 UTC and eventually returned 200; it did not reproduce the persistent self-redirect. Comparing affected and unaffected edge locations, CF-Ray/cache headers and origin responses may be necessary.

Workaround verified downstream

Use the document's explicit format URL:

• https://www.rfc-editor.org/rfc/rfc8621.html: local GET returned 200 without redirects at 06:14:38 UTC.
• https://www.rfc-editor.org/rfc/rfc8621.txt: local GET also returned 200 without redirects.

We updated all four downstream documentation references in link-foundation/meta-sovereign#53. The link gate remains strict; no URL exception, accepted-error status or increased timeout was added.

Suggested investigation and code repair

Source review at 5d5e4ec6e7e6214f54c0366d264e74fd4fc1144f finds the expected legacy redirect in worker/src/blobs.ts (blobsRfc, extensionless RFC branch). /info/ goes through the origin fallback in worker/src/index.ts. In worker/src/helpers.ts, staleWhileRevalidate deliberately fetches redirects manually and caches 301/302/307/308 per edge location. These facts identify useful tracing points; they do not prove which layer produced the observed self-redirect or which revision was deployed.

Suggestions:

1. Trace the canonical /info/rfc8621/ request through origin trailing-slash/canonical-host rules and worker cache, retaining request URL, resolved Location, status, cache state and edge identifier. Put additional diagnostic logging behind a default-off flag.
2. Before caching/forwarding a redirect in staleWhileRevalidate, compare its resolved Location with the normalized request URL; reject/log a self-redirect and invalidate an already cached self-redirect. Correct the actual origin/canonicalization rule rather than returning a synthetic success. Purge affected cached 301s if confirmed.
3. Add tests covering extensionless RFC → info page, slash/no-slash canonical info URLs, GET and HEAD, cached self-redirect rejection, and an end-to-end bounded chain that terminates with 200. Ensure an already canonical URL is served rather than redirected to itself.

Preserved full logs, HTTP headers/statuses, and immutable source excerpts will be available in the checksummed evidence archive under dev/log/issues/52/pulls/53/ in the downstream PR.