On 25 September 2014 07:16, Alan Kennedy <a...@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 _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
