What is the crux of the problem you are trying to solve?
Lactoserv should be able to operated behind a reverse proxy, though it will need to be configurable whether it should operate that way.
Specifically, it needs to be able to recognize the Forwarded header when so configured, and use its info when constructing the corresponding Request object.
What is the shape of the solution?
- Add a
reverseProxy configuration to ProtocolWrangler, which has sufficient semantics to define how to treat Forwarded (etc.) headers.
- Add a way to construct a
Request with replacement values; this may or may not involve actual additional logic in the Request constructor. For example, it might make sense to define a wrapper around the underlying express.Request / IncomingMessage which "covers" things like .remoteAddress and get('host'), which would let Request blithely request the usual properties [waves hands].
Is there a workaround?
Not really. This needs to be handled at the framework level.
Additional context
The Forwarded header is the most modern way to convey this info, but there are a few X- headers that are de facto standard and perhaps should be (configurable to be) honored.
See these:
What is the crux of the problem you are trying to solve?
Lactoserv should be able to operated behind a reverse proxy, though it will need to be configurable whether it should operate that way.
Specifically, it needs to be able to recognize the
Forwardedheader when so configured, and use its info when constructing the correspondingRequestobject.What is the shape of the solution?
reverseProxyconfiguration toProtocolWrangler, which has sufficient semantics to define how to treatForwarded(etc.) headers.Requestwith replacement values; this may or may not involve actual additional logic in theRequestconstructor. For example, it might make sense to define a wrapper around the underlyingexpress.Request/IncomingMessagewhich "covers" things like.remoteAddressandget('host'), which would letRequestblithely request the usual properties [waves hands].Is there a workaround?
Not really. This needs to be handled at the framework level.
Additional context
The
Forwardedheader is the most modern way to convey this info, but there are a fewX-headers that are de facto standard and perhaps should be (configurable to be) honored.See these: