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 <robe...@robertcollins.net> wrote: > 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
