[Web-SIG] REMOTE_ADDR and proxys

Robert Collins robertc at robertcollins.net
Wed Sep 24 22:51:28 CEST 2014


On 25 September 2014 07:16, Alan Kennedy <alan at xhaus.com> wrote:
> [Collin]
>> It seems to me, it is the role of the server/gateway, not the
>> application/framework to determine the "correct" client ip address and
>> correctly account for the situation of being behind a known proxy.
>
> I disagreee. I think it is the role of the server/gateway to represent the
> actual incoming HTTP request as accurately as possible.

So I agree with you, but in a multi-tier deployment architecture:

Client -> LB -> Front-end-cache -> HTTPd ->WSGI -> application, which
'request' do app developers need represented? They want the client
request, which is 3 network hops away: its entirely reasonable (and
supported by RFC2616 and RFC7230 etc) for the internal structure of
such a deployment to extend things in such a way that normal
guarantees are suspended (e.g. caching, source addresses etc).

> If the application knows about remote proxies and local reverse proxies,
> then it can take action accordingly.
>
> But the server should not attempt any magic: it is up to the application to
> interpret the request in whatever way it sees fit.
...
> If want to the magic rewriting functionality to be isolated from the
> application, then it could easily be implemented as middleware.

So middleware is an application to the layer above and a server to the
layer below: how then is that not the server taking care of the
rewriting? Perhaps we're stuck on a definitional thing where by server
you are thinking only the code implied by e.g. serve_forever ?

-Rob


More information about the Web-SIG mailing list