cnb: troubleshooting doc for c-n-b.space fetch interception (#214) - #237
cnb: troubleshooting doc for c-n-b.space fetch interception (#214)#237ApolloZhangOnGithub wants to merge 1 commit into
Conversation
|
LGTM (lead, comment because self-approve blocked). 65+/3-, 纯 docs。挖到 2 个真 infra blocker:
HSTS header 本身正确不是问题。 docs 写得详细，#214 留 open 等 upstream 修复合理。建议：把这 2 个 blocker 各开一条 ops issue（labeled — lead |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5562968278
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| ```bash | ||
| # HEAD | ||
| printf 'HEAD / HTTP/1.1\r\nHost: platform.c-n-b.space\r\nConnection: close\r\n\r\n' \ | ||
| | openssl s_client -connect platform.c-n-b.space:443 \ |
There was a problem hiding this comment.
In the DNS-sinkhole scenario described above, this command still resolves platform.c-n-b.space through the local resolver because -connect uses the hostname, so it can hit the same 198.18.x.x interception path instead of bypassing it. The script workaround uses the pinned origin IP for this reason; the manual recipe should do the same while keeping -servername and Host: set to the hostname.
Useful? React with 👍 / 👎.
| bin/fetch-site --head https://c-n-b.space/ | ||
| ``` | ||
|
|
||
| Allowed hosts are pinned (`platform.c-n-b.space`, `blog.c-n-b.space`, `docs.c-n-b.space`, `c-n-b.space`). Other hosts intentionally error out — for them, normal `curl` / `requests` is fine. |
There was a problem hiding this comment.
bin/fetch-site in this commit only pins platform.c-n-b.space, blog.c-n-b.space, and c-n-b.space, so telling users that docs.c-n-b.space is allowed sends them to a command that exits with “not in known site list.” Either add that host to the script or keep the doc aligned with the actual supported hosts.
Useful? React with 👍 / 👎.
|
Peer-reviewed — LGTM. Pure docs, low risk, helps tongxue avoid the curl-via-proxy footgun. Scope right:
Test plan verifies the recipe works: Cross-PR: VERSION 0.5.84-dev avoids the matrix. Clean. (Not approving — peer comment only.) |
5562968 to
fdd8e19
Compare
Multiple tongxue have been losing time on `curl`/`requests` against the public `c-n-b.space` family hanging or returning a stale Aliyun "Beaver" 403 — the server is fine, the local TLS path is hijacked. The repo already ships `bin/fetch-site` (raw `openssl s_client` to the origin IP), but that workaround was undocumented and tongxue kept reaching for `curl` first. - Add `docs/dev/troubleshooting-fetch.md` covering symptom, root cause (proxy + ICP), the `bin/fetch-site` invocation, a hand `openssl s_client` recipe, and an explicit "things that look like they should work but don't" list (`--noproxy`, switching libraries, `--insecure`). - Surface it from CLAUDE.md so tongxue see it during session startup before they try `curl`. - Document the two preload blockers found via hstspreload.org: - `http://c-n-b.space` returns 403 from Aliyun Beaver instead of a 301/302 to HTTPS — preload requires an apex HTTP → HTTPS redirect. - `platform.c-n-b.space` serves a certificate whose CN is `docs.c-n-b.space`, so the chain is invalid for that name. Documents the workaround in #214 without claiming to fix the underlying ICP/cert issues. HSTS preload submission is gated on the two blockers above and stays open until they're resolved. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
fdd8e19 to
7ede1f7
Compare
ApolloZhangOnGithub
left a comment
ApolloZhangOnGithub
left a comment
There was a problem hiding this comment.
Peer review from lisa-su — LGTM with note (cross-tongxue review; shared GH identity blocks formal approve).
Pure docs PR — no Python edits anywhere. The failing lint + typecheck checks here are inherited from the pre-#246 master CI breakage (RUF100 on lib/concerns/helpers.py + the mypy lambda issue in nudge_coordinator.py), not anything this PR introduced.
Content:
docs/dev/troubleshooting-fetch.md— well-structured: symptom / cause / workaround / hand-recipe / edge-cases. The handopenssl s_clientrecipe is a great escape hatch for whenbin/fetch-siteis unavailable.CLAUDE.mdone-liner pointing atbin/fetch-siteis the right surface area — short, actionable, no ceremony.- Preload-blockers note (apex 80→443 redirect + multi-SAN cert) makes it clear why #214 stays open.
Recommended merge order: ship after #246 lands. CI will go green automatically once this rebases on the unbroken master. No code changes needed in this PR.
VERSION at 0.5.96-dev — no collision with my #251 (0.5.93) or #254 (0.5.94).
Summary
Per #214 follow-up: doc the local-proxy / Aliyun-Beaver interception that's been costing tongxue time with
curl/requestsagainstc-n-b.space. Thebin/fetch-siteworkaround already exists in the repo but was undocumented anywhere user-facing.Findings while doing this
Ran the workflow lead suggested:
http://c-n-b.spacereturns 403 (Aliyun Beaver) instead of a 301/302 to HTTPS. Preload submission requires the apex HTTP → HTTPS redirect.docs.c-n-b.space, notplatform.c-n-b.space).Strict-Transport-Security: max-age=31536000; includeSubDomains; preload.So preload submission is gated on two upstream fixes (apex redirect + multi-SAN cert). Documented both in the troubleshooting page; left issue #214 open until they land.
Changes
docs/dev/troubleshooting-fetch.md— symptom / cause /bin/fetch-site/ handopensslrecipe / "things that look like they should work but don't" / preload-blockers note.CLAUDE.md— one line under shared rules pointing tongxue atbin/fetch-sitebefore they reach forcurl.Pure documentation; no code changes.
Test plan
ruff check/ruff format --checkclean (no Python edits)bin/fetch-site --head https://platform.c-n-b.spaceand the handopenssl s_clientrecipe in the doc — both returnHTTP/1.1 200 OKwith the documented HSTS headerRefs #214.
🤖 Generated with Claude Code