Add Keep-Alive Context Isolation Tests (Issue #29)

[bgruszka]

Description

Adds comprehensive tests to verify that HTTP Keep-Alive connection reuse does not leak request context (headers, propagated data) between different requests on the same TCP connection.

Fixes #29

Problem Statement

HTTP Keep-Alive allows multiple requests to be sent over a single TCP connection. This raises a critical security concern: if the proxy maintains request-specific state in connection-level storage or global variables, one request's context could be visible to subsequent requests on the same connection.

Security Risks:

• Header values leaking between requests
• User context bleeding to different requests
• Propagated request IDs appearing in wrong requests
• Data isolation violations

Solution

Added two comprehensive test suites:

1. Unit Tests (internal/handler/keepalive_isolation_test.go)

Seven unit tests covering:

Test	What It Verifies
TestKeepAliveContextIsolation_SequentialRequests	Sequential requests on the same Keep-Alive connection don't leak headers
TestKeepAliveContextIsolation_ConcurrentRequests	100 concurrent requests don't cross-contaminate
TestKeepAliveContextIsolation_RawTCPConnection	Uses raw TCP to guarantee connection reuse, verifies isolation
TestKeepAliveContextIsolation_GlobalStateNotShared	Handler-level state doesn't leak between requests
TestKeepAliveContextIsolation_TransportRoundTrip	HeaderPropagatingTransport doesn't share state
TestKeepAliveContextIsolation_RapidSequential	1000 rapid sequential requests maintain isolation
TestKeepAliveContextIsolation_HTTP11Pipelining	HTTP/1.1 pipelining isolates context correctly

2. E2E Tests (tests/e2e/keepalive_isolation_test.go)

Four Kubernetes e2e tests covering:

Test	What It Verifies
Sequential requests on Keep-Alive	Sends 3 requests with different headers, verifies no leakage
Concurrent requests with Keep-Alive	10 concurrent requests, each gets only its own context
Rapid sequential stress test	50 rapid requests, checks for any cross-contamination
HTTP/1.1 pipelining simulation	Uses netcat to send pipelined requests, verifies isolation

Test Results

All tests pass ✅

$ go test ./internal/handler/... -run "KeepAlive" -count=1
ok  	github.com/bgruszka/contextforge/internal/handler	0.699s

$ go test ./... -count=1
# All unit tests pass (e2e requires K8s cluster)

Why This Matters

The implementation correctly isolates context because:

1. Request-scoped context: Each request creates a new context via context.WithValue(r.Context(), ContextKeyHeaders, headerMap)
2. Per-request header extraction: extractHeaders() creates a fresh map[string]string for each request
3. Transport gets headers from request context: GetHeadersFromContext(req.Context()) is request-scoped, not connection-scoped

The tests confirm no context leakage occurs even with Keep-Alive connection reuse.

Changes

• ✅ Added internal/handler/keepalive_isolation_test.go (513 lines, 7 tests)
• ✅ Added tests/e2e/keepalive_isolation_test.go (425 lines, 4 e2e tests)
• ✅ All tests pass
• ✅ Linter clean (golangci-lint run)
• ✅ No code changes required (current implementation is secure)

Testing Checklist

• Unit tests pass
• Linter passes
• E2E tests compile (require K8s cluster to run)
• Sequential request isolation verified
• Concurrent request isolation verified
• Raw TCP connection reuse tested
• HTTP/1.1 pipelining tested

Security Validation

These tests serve as regression protection to ensure future changes don't introduce context leakage vulnerabilities in Keep-Alive scenarios.