mirror of
https://github.com/wweir/sower.git
synced 2026-10-20 00:15:34 +00:00
A site route always rewrote the outbound Host to the upstream host, so an upstream that validates the authority it is visited under could not sit behind one: pi-web compares Origin's host against the Host header, answers 403 to every browser-originated /api request, and the page loads while its WebSocket never connects. Add `authority = "upstream" | "client"` to a site route, defaulting to "upstream" so existing routes keep the current behavior byte for byte. "client" forwards the authority the client asked for, which is what such an upstream needs; its own allowlist must still name the public domain (pi-web's PI_WEB_ALLOWED_HOSTS), because the forwarded name is client-controlled. The key is one word on purpose: aconfig v0.19.0 title-cases the keys of an array-of-tables element, so `preserve_host` is rejected at load time — probed before the spelling was chosen. - config: SiteRoute.Authority, the AuthorityUpstream/AuthorityClient values, and SiteRoute.PreserveHost(). Validate rejects an unknown value instead of silently defaulting, since the two values differ in what the upstream sees. - cmd/sowerd: newSiteRouter feeds that flag into the siteEntry field the fake-site fallback already used. - docs: ARCHITECTURE.md and security.md record the rule, why the adaptation belongs to the edge rather than to an upstream trusting X-Forwarded-Host, and what preserving a client-controlled authority does not protect. - tests: TOML round-trip, unknown-value rejection, router plumbing, and an end-to-end handleConn case asserting the upstream sees the client's name.
Documentation Index
This directory contains long-lived design documents. Per AGENTS.md rules:
docs/root holds only finalized, authoritative design documents (product, architecture, protocol, security, deployment, data model, test strategy, etc.).docs/plans/holds draft proposals and in-progress implementation plans — not authoritative.docs/reviews/holds review records, issue lists, and retrospective summaries — not authoritative.
When a plan or review produces a durable rule, it must be written back to the relevant root-level design document and referenced from this index.
Cross-document references must point to root-level design documents only. Never reference protocol, field, security, or deployment rules from plans/ or reviews/.
Root-Level Documents
| Document | Description |
|---|---|
| ARCHITECTURE.md | System boundary, layer responsibilities, data flows, design decisions |
| security.md | sowerd edge threat model, anti-probing layers, unknown-SNI certificate fallback, rejected directions |
Plans
Historical plans live under docs/plans/ and are not authoritative. Durable rules from completed plans are reflected only in the root-level documents listed above.
Reviews
No reviews yet.