An endpoint passes every in-process test but misbehaves behind a TLS-terminating proxy in production - how would you test for that class of fault?

## Why the fast suite was green An in-process test client builds the request, including everything the application later reads about the connection. If the handler asks whether the request arrived securely, or what the client address was, or reads a header a proxy is supposed to add, the answer is whatever the test wrote. The test therefore encodes **your assumption about the deployment** and then asserts that assumption back to you. When production disagrees - the terminator is somewhere else, the trusted peer list is empty, the added header never arrives - the test cannot notice, because the disagreement is with the configuration, and the configuration is not in the path. This is the sharpest version of the general rule: an in-process pass proves things about the application, not about the deployment. ## The symptoms this fault class produces | Symptom | What the application got wrong | |---|---| | Generated absolute links and redirect targets use the wrong scheme or host | It inferred the external address from the local connection instead of the terminating hop | | A cookie marked for secure transport only is never set, or is set when it should not be | It decided the connection was insecure because the terminator is a separate hop | | An infinite redirect loop between the application and the terminator | Each side believes the other should perform the upgrade | | Client addresses in logs and rate limits are all the same value | It read the peer address, which is the proxy, not the client | | A client can spoof an identity by sending a header itself | The header is trusted from any peer, not only the terminating hop | ## How to reproduce it deliberately 1. **Start the real listener** with the configuration the deployment uses - the same trust settings, the same address handling, the same secure-transport setting. Bind port `0` so parallel runs do not collide. 2. **Put the terminating hop in front of it** in the test, or stand in for it precisely: a client that connects to the application the way the hop would, sending the same added headers from the same peer. 3. **Assert on what an external client sees**, not on an internal flag: the scheme and host of an absolute link or redirect target, the attributes on a set cookie, the status. Those are the things users and browsers act on. 4. **Test the trust boundary in both directions.** Send the proxy-added header from an untrusted peer and assert it is ignored; send it from the trusted one and assert it is honoured. A test that only covers the honoured direction turns a spoofing hole into a passing suite. 5. **Test the direct path too.** Something usually can still reach the application without going through the hop. Decide what should happen then - refuse, redirect, or treat as insecure - and assert it. ## Keeping it proportionate These tests are slow and they encode deployment shape, so they rot when the topology changes. That argues for a handful, not a suite: - one case per **decision** the application makes from connection facts, not one per route; - run them on every change to the listener or trust configuration, and on a schedule; - when the topology changes - the terminator moves, a hop is added - treat these tests as the first thing to update, because their whole value is that they encode the shape; - pair them with a post-deploy check against the real environment, since only that sees the real hop. ## Where the assumption is actually stored It is worth being precise about what fails here, because the instinct is to go looking in the handler. The handler is usually fine: given a request that says the connection was secure and came from a particular client, it does the right thing. What is wrong is **the pipeline that produces that statement** - the listener's own security setting, the list of peers whose added headers are trusted, and whether the hop in front is adding them at all. None of that is code you wrote; it is configuration, and configuration only participates when a real listener starts. That is the whole reason the fault class survives a fast suite of any size. ## The habit worth forming When you read a handler, notice every place it consults something about the connection rather than about the request's content. Each of those is a line an in-process test cannot exercise honestly, and each is a candidate for one of the few tests that go over the wire. That short list, rather than a general instinct that integration tests are better, is what decides where the expensive coverage goes.