[Web-SIG] REMOTE_ADDR and proxys

[Collin Anderson]

Thanks guys. So it sounds like it should be the responsibility of a
middleware to re normalize the environment?

On Wed, Sep 24, 2014 at 4:51 PM, Robert Collins <robertc at robertcollins.net>
wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20140929/7ee04e93/attachment-0001.html>