mc-proxy/PROGRESS.md

PROGRESS.md

Tracks implementation status against PROJECT_PLAN.md. Updated as work proceeds. Each item is marked:

• [ ] not started
• [~] in progress
• [x] complete
• [—] skipped (with reason)

---

Phase 1: Database & Config Foundation

• 1.1 Config struct updates (Listener.ProxyProtocol, Route.Mode/TLSCert/TLSKey/BackendTLS/SendProxyProtocol)
• 1.2 Config validation updates (L7 requires cert/key, mode enum, cert/key pair loading)
• 1.3 Database migration v2 (new columns on listeners and routes)
• 1.4 DB struct and CRUD updates (new fields in Listener, Route, all queries)
• 1.5 Server data loading (RouteInfo struct replaces bare backend string in route lookup)
• 1.6 Tests (config, DB migration, CRUD, server unchanged)

Phase 2: PROXY Protocol

• 2.1 internal/proxyproto/ package (v1/v2 parser, v2 writer)
• 2.2 Server integration — receive (parse PROXY header before firewall on enabled listeners)
• 2.3 Server integration — send on L4 (write PROXY v2 header before ClientHello on enabled routes)
• 2.4 Tests (receive, send, firewall uses real IP, malformed header rejection)

Phase 3: L7 Proxying

• 3.1 internal/l7/ package (PrefixConn, HTTP/2 reverse proxy with h2c, Serve entry point)
• 3.2 Server integration (dispatch to L4 or L7 based on route.Mode in handleConn)
• 3.3 PROXY protocol sending in L7 path
• 3.4 Tests (TLS termination, h2c backend, re-encrypt, mixed L4/L7 listener, gRPC through L7)

Phase 4: gRPC API & CLI Updates

• 4.1 Proto updates (new fields on Route, AddRouteRequest, ListenerStatus)
• 4.2 gRPC server updates (accept/validate/persist new route fields)
• 4.3 Client package updates (new fields on Route, ListenerStatus)
• 4.4 mcproxyctl updates (flags for routes add, display in routes list)
• 4.5 Tests (gRPC round-trip with new fields, backward compatibility)

Phase 5: Integration & Polish

• 5.1 Dev config update (srv/mc-proxy.toml with L7 route example)
• 5.2 Multi-hop integration test (edge→origin via PROXY protocol)
• 5.3 gRPC-through-L7 validation (trailer propagation, large responses)
• 5.4 Web UI through L7 validation (HTTP/1.1 fallback, HTTP/2)
• 5.5 Documentation (verified ARCHITECTURE.md, CLAUDE.md, Makefile)

Phase 6: Per-Listener Connection Limits

• 6.1 Config: MaxConnections on Listener, validation
• 6.2 DB: migration 3, CRUD updates, UpdateListenerMaxConns
• 6.3 Server: limit enforcement in serve(), SetMaxConnections method
• 6.4 Proto/gRPC: SetListenerMaxConnections RPC, max_connections in status
• 6.5 Client: SetListenerMaxConnections method, MaxConnections in status
• 6.6 Tests: DB CRUD, server limit enforcement, gRPC round-trip

Phase 7: L7 Policies

• 7.1 Config: L7Policy struct, L7Policies on Route, validation
• 7.2 DB: migration 4, l7_policies table, CRUD in l7policies.go
• 7.3 L7 middleware: PolicyMiddleware in internal/l7/policy.go
• 7.4 Server/L7 integration: thread policies from RouteInfo to RouteConfig
• 7.5 Proto/gRPC: L7Policy message, policy management RPCs
• 7.6 Client/CLI: policy methods, mcproxyctl policies subcommand
• 7.7 Startup: load L7 policies per route in loadListenersFromDB
• 7.8 Tests: middleware unit, DB CRUD + cascade, gRPC round-trip, e2e

Phase 8: Prometheus Metrics

• 8.1 Dependency: add prometheus/client_golang
• 8.2 Config: Metrics section (addr, path)
• 8.3 Package: internal/metrics/ definitions and HTTP server
• 8.4 Instrumentation: connections, firewall, dial latency, bytes, HTTP status, policy blocks
• 8.5 Firewall: BlockedWithReason() method
• 8.6 L7: status recording on ResponseWriter
• 8.7 Startup: conditionally start metrics server
• 8.8 Tests: metric sanity, server endpoint, BlockedWithReason

---

Current State

Phases 1-8 complete. Prometheus metrics are instrumented across connections, firewall, dial latency, bytes transferred, L7 HTTP status codes, and L7 policy blocks.

go vet and go test pass across all 14 packages.