Re: REMOTE_ADDR and proxys
Collin Anderson <[email protected]> Mon, 29 Sep 2014 17:14:20 -0400
| Newsgroups | gmane.comp.python.web |
|---|---|
| Message-ID | <CAFO84S4di9W6p6X7Lwh-vmcL=4pQfw=77EY6MsBKOwOSRiU4QQ@mail.gmail.com> |
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 <[email protected]> wrote: > On 25 September 2014 07:16, Alan Kennedy <[email protected]> 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 [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org