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

Open
  • Is something wrong?
#577 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript
Domain
backend, devops

Research direction

Start by tracing /info/ through worker/src/index.ts, then inspect redirect handling and caching in worker/src/helpers.ts and the RFC routing in worker/src/blobs.ts. Compare request URLs, resolved Location headers, cache state, and edge identifiers for affected and unaffected requests; the report does not establish which layer caused the observed loop. Done means the confirmed cause is fixed, self-redirects are rejected or invalidated, and tests cover canonical URLs and bounded chains ending in 200.

Written by the indexing model from the issue text.

Description

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 https://github.com/link-foundation/meta-sovereign/pull/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.

Dominant language
HTML
Stars
18
Forks
21
Avg merge
11h 11m
Merged PRs (30d)
6

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

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 ietf-tools/red

All issues in ietf-tools/red

Similar issues

More Backend & API Design issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.