Repository navigation
Edge request handling has to be discovered by probing #61
Description
What needs to happen
Someone putting an application behind our edge needs to know what we do to their requests before the origin sees them, and today they find out by sending probes and reading what comes back. A user building on the platform ran a series of experiments against a test origin to learn which header carries the real client address, how long a response may stay open, and what happens to traffic arriving on the plain HTTP port. All three are stable, knowable properties of the edge that we simply never wrote down.
Why this matters
Every rate limiter, audit log and geo rule in a customer application depends on knowing which header holds the client address, and getting it wrong is a security bug rather than an inconvenience. The other two answers decide whether a design works at all: an application built around streaming responses will be cut off, and one assuming a redirect from plain HTTP will not get one. Discovering any of this by experiment costs hours and leaves the user unsure whether what they measured is a promise or an accident.
Desired outcome
- The proxy documentation names the header that carries the client address, and says which client-supplied forwarding headers are stripped or rewritten
- The documentation states how long a response may stay open before the edge closes it
- The documentation says what happens to requests arriving over plain HTTP, and how to get a redirect today
- A reader can answer all three without sending a single probe
Related to datum-cloud/network-services-operator#459
Related to datum-cloud/network-services-operator#460
Metadata
Metadata
Assignees
Labels
Type
Fields
Priority
Activity
0xmc commentedon Sep 14, 2026
The measurements behind this, taken on 2026-09-04 around 21:00 UTC through a proxy pointed at a public request-echo service, so the numbers are reproducible.
The origin saw
X-Envoy-External-Addresscarrying the client address, and it was correctly overwritten when the client sent a fake one. It did not seeX-Forwarded-FororX-Forwarded-Protoat all, and a client-suppliedX-Forwarded-For: 1.2.3.4vanished rather than being appended. So the client address is available, just not where a proxy-aware application looks for it by default.A response deliberately held open for twenty-five seconds was closed at about sixteen, which reads as the default fifteen second route timeout, and the proxy schema exposes nothing to change it.
Plain HTTP was served normally with no redirect. There is no scheme matcher and no force-HTTPS field in the API, so the pattern the user shipped matches
X-Forwarded-Protoexactly equal tohttpand applies a redirect to thehttpsscheme. That works only because the edge sets that header before route matching — worth documenting as the supported pattern, or superseding with a real field.0xmc commentedon Oct 5, 2026
The missing forwarding headers are now tracked as a product defect in datum-cloud/network-services-operator#540. The client-address checkbox here should document whatever that issue settles on.