27 lines
1.3 KiB
Markdown
27 lines
1.3 KiB
Markdown
|
# 1.1 — Reverse proxy to configured upstreams (GREEN)
|
||
|
|
|
||
|
|
Phase: 1 — Proxy core
|
||
|
|
Stage: GREEN
|
||
|
|
Depends on: [0.2](0.2-route-configuration.md), [0.4](0.4-local-dev-harness.md)
|
||
|
|
|
||
|
|
- [ ] A request matching a configured route is proxied to that route's upstream address
|
||
|
|
- [ ] The upstream's status code, response headers and body reach the client unmodified
|
||
|
|
- [ ] The request method, query string and body reach the upstream unmodified
|
||
|
|
- [ ] The route's configured path rewrite is applied to the upstream request path
|
||
|
|
- [ ] Connections to upstreams are pooled and reused across requests — a second request to the same upstream does not open a new TCP connection
|
||
|
|
- [ ] A request matching no configured route returns `404` and contacts no upstream
|
||
|
|
- [ ] An unreachable upstream returns a `5xx` to the client and is logged with the upstream name
|
||
|
|
|
||
|
|
Connection reuse is not a micro-optimisation here: the chat upstreams hold long-lived
|
||
|
|
streaming responses, and churning connections under that pattern wastes handshakes and
|
||
|
|
file descriptors on both ends.
|
||
|
|
|
||
|
|
## Verify
|
||
|
|
|
||
|
|
```bash
|
||
|
|
go test ./internal/proxy/... -run 'TestProxy|TestConnectionReuse' -v
|
||
|
|
# expected: passes — stub upstream sees the rewritten path and original body, client
|
||
|
|
# sees the stub's exact status/headers/body, and the stub records one accepted
|
||
|
|
# connection across two sequential requests
|
||
|
|
```
|