glm-5.1
9a2352e61c
Resolve open questions: - OQ-01: Restrict cipher suites to match nginx scope (4 ECDHE-AES-GCM suites for TLS 1.2 + all TLS 1.3 suites) — ADR-012 - OQ-03: Health check on separate local port (default 9900, localhost only) — ADR-013 - OQ-04: Add Unix domain socket admin API for config reload alongside SIGHUP, with structured success/failure responses — ADR-014 - OQ-06: Per-site upstream timeouts with defaults (5s connect, 60s request), overridable in SiteConfig — ADR-015 Document previously undocumented decisions flagged by architecture review: - ADR-016: Explicit bind address requirement (reject 0.0.0.0) - ADR-017: Upstream connection defaults (HTTP/1.1, no redirects, pooling) - ADR-018: 100 MB body size limit (matches nginx, Gitea compatibility) OQ-07 (per-site TLS overrides) remains open for future consideration. Spec updates: - config.md: add health_check_port, admin_socket_path, per-site timeout fields, update TOML example and validation rules - proxy.md: reference ADR-015/017/018 for timeouts, connection defaults, and body limit decisions - tls.md: replace OQ-01 cipher suite section with ADR-012 decision - operations.md: add local health check port section, admin socket reload - overview.md: update Phase 1 scope with new features, add ADR references - open-questions.md: resolve OQ-01/03/04/06, keep OQ-07 open
1.8 KiB
1.8 KiB
ADR-018: Request Body Size Limit
Status
Accepted
Context
The proxy enforces a maximum request body size to protect against resource exhaustion attacks. The default limit must balance security with usability.
Gitea push operations can involve large Git pack files. The current nginx
configuration uses client_max_body_size 100m, and Gitea's documentation
recommends allowing up to 100 MB for push operations.
Decision
Set the default request body size limit to 100 MB (104,857,600 bytes),
matching our current nginx configuration. The limit is global in Phase 1
(configurable via body.limit_bytes in DynamicConfig).
Rationale
- 100 MB matches the current nginx
client_max_body_size 100m, ensuring behavioral parity during migration - Gitea push operations with large repositories regularly exceed 50 MB
- 100 MB is large enough for any legitimate Git operation while still providing protection against resource exhaustion (a 100 MB body is not enough to exhaust memory on modern servers, but prevents unbounded uploads)
- The limit is configurable — operators can reduce it for deployments that don't need large uploads
- In Phase 2, per-site limits will allow different limits for different upstreams (e.g., a lower limit for alk.dev, the current limit for git.alk.dev)
Consequences
Positive:
- Behavioral parity with current nginx configuration
- Gitea push operations work without configuration changes
- Configurable for deployments with different needs
Negative:
- 100 MB is a generous default — some deployments may want a lower limit (mitigated by configurability)
- Global limit means all sites share the same maximum (mitigated by Phase 2 per-site limits)