nginx/HTTPS/HTTP proxy to Apache/HTTP.
Graham Dumpleton
whether doing things that aren't needed.
This is not for me, someone else is after it and want to understand
what is required.
What is desired is to have nginx in front of Apache/mod_wsgi. The
nginx would serve static files, and proxy dynamic requests to
Apache/mod_wsgi.
That bit is okay, but want nginx to listen for both HTTPS and HTTP requests.
If nginx accepts both HTTPS and HTTP inbound requests, but the proxy
connections to Apache/mod_wsgi uses HTTP, then on Apache/mod_wsgi side
wsgi.url_scheme will be http for both the original HTTPS and HTTP
requests. Thus WSGI application can't tell if original request
received by nginx was secure. Note am assuming here that nginx
connection to Apache/mod_wsgi is via localhost and on secure box.
My assumption here is that nothing else in headers passed from nginx
will indicate that original request was HTTPS.
One way I saw as away around this was to use on nginx side:
proxy_set_header X-Proxy-Host $proxy_host;
This would have effect of setting header in proxied request of form:
X-Proxy-Host: originalhost:80
for HTTP and:
X-Proxy-Host: originalhost:443
for HTTPS.
In the WSGI script file for Apache/mod_wsgi, could then use a WSGI
middleware to do something like:
def application(environ, start_response):
if environ['HTTP_X_PROXY_HOST'].split(':')[1] == '443':
environ['wsgi.url_scheme'] = 'https'
return _application(environ, start_response)
For nginx as front end to Apache/mod_wsgi does this make sense and/or
is there a better way of getting to the Apache/mod_wsgi a flag
indicating that original request was HTTPS rather than plain HTTP.
Graham
Graham Dumpleton
proxy_set_header Host $host;
Then HTTP_HOST will have port 80/443 in it. The proxy_port is what the
proxy is connecting to. Yes/No?
Graham
2008/10/18 Graham Dumpleton <graham.d...@gmail.com>:
MJBoa
And I don't see a way anywhere in the nginx documentation to get the
port that nginx got the request on.
On Oct 18, 3:52 am, "Graham Dumpleton" <graham.dumple...@gmail.com>
wrote:
>
> proxy_set_header Host $host;
>
> Then HTTP_HOST will have port 80/443 in it. The proxy_port is what the
> proxy is connecting to. Yes/No?
>
> Graham
>
Graham Dumpleton
sections distinct such that we could put different proxy_set_header
directives in each?
May have to troll through nginx source code to find out what all the
variables are that can be used as value for proxy_set_header.
Graham
2008/10/18 MJBoa <mjb...@gmail.com>:
Graham Dumpleton
proxy_set_header X-Nginx-Port $server_port;
proxy_set_header X-Nginx-Host $host;
see HTTP_X_NGINX_PORT and HTTP_X_NGINX_HOST being set to in WSGI script environ?
Graham
2008/10/18 Graham Dumpleton <graham.d...@gmail.com>:
Graham Dumpleton
> What does:
>
> proxy_set_header X-Nginx-Port $server_port;
> proxy_set_header X-Nginx-Host $host;
>
> see HTTP_X_NGINX_PORT and HTTP_X_NGINX_HOST being set to in WSGI script environ?
Even better, what does:
proxy_set_header X-Nginx-Scheme $scheme;
end up as being.
MJBoa
though. Do you know by any chance where wsgi gets wsgi.url_scheme
from? Is there some header I can change where wsgi will read that its
https or http sos this works automatically? That'd be so much more
satisying.
On Oct 18, 4:53 am, "Graham Dumpleton" <graham.dumple...@gmail.com>
wrote:
> 2008/10/18 Graham Dumpleton <graham.dumple...@gmail.com>:
> > What does:
>
> > proxy_set_header X-Nginx-Port $server_port;
> > proxy_set_header X-Nginx-Host $host;
>
> > see HTTP_X_NGINX_PORT and HTTP_X_NGINX_HOST being set to in WSGI script environ?
>
> Even better, what does:
>
> proxy_set_header X-Nginx-Scheme $scheme;
>
> end up as being.
>
> > Graham
>
Graham Dumpleton
>
> Awesome, both $server_port amd $scheme work. $scheme is more awesome
> though. Do you know by any chance where wsgi gets wsgi.url_scheme
> from? Is there some header I can change where wsgi will read that its
> https or http sos this works automatically? That'd be so much more
> satisying.
So, in summary on nginx side we can use:
proxy_set_header X-Url-Scheme $scheme;
and on Apache/mod_wsgi side, with Django 1.0 as an example, in WSGI
script file we would have:
import os, sys
sys.path.append('/usr/local/django')
os.environ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings'
import django.core.handlers.wsgi
_application = django.core.handlers.wsgi.WSGIHandler()
def application(environ, start_response):
environ['wsgi.url_scheme'] = environ.get('HTTP_X_URL_SCHEME', 'http')
return _application(environ, start_response)
There is no inbuilt feature in mod_wsgi to allow the wsgi variables to
be overridden using mod_env, mod_rewrite or mod_headers. This is
because the incidences where it would be required would be very few.
Thus any fixups to WSGI environment would need to be done in the WSGI
script itself.
I was toying for a while with the idea of a WSGIHandlerScript
directive which would allow one to define a WSGI application object to
be executed in place of the actual target one.
One aspect of that would have potentially been the target being passed
through WSGI environment, exactly so that a web hoster could apply
fixups or insert WSGI middleware, without user knowing and then
executing the target WSGI application.
I turned people off the idea somewhat I think when I described another
way it might be applied for which people couldn't see the point and
rather I stick to plain WSGI. It was thus left out. That discussion
can be found at:
http://groups.google.com/group/modwsgi/browse_frm/thread/68a7f6044c9b3360
I may still resurrect that idea though as it would be a useful hook
for some companion debugging tools am interested in developing at some
point. Yes the hook isn't strictly needed, but would be a way of a web
hoster providing value add transparently without having to explain to
users how to add middleware components in themselves.
Graham