Files
sower/docs
wweir d15ba70100 feat(sowerd): let a site route present the client's authority to its upstream
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.
2026-10-12 14:35:41 +08:00
..

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.