WSGIProxy Modules

wsgiproxy.app – HTTP Proxying as a WSGI Application

class wsgiproxy.app.WSGIProxyApp(href, secret_file=None, string_keys=None, unicode_keys=None, json_keys=None, pickle_keys=None)

wsgiproxy.exactproxy – No-frills proxying

wsgiproxy.exactproxy.proxy_exact_request(environ, start_response)

HTTP proxying WSGI application that proxies the exact request given in the environment. All controls are passed through the environment.

This connects to the server given in SERVER_NAME:SERVER_PORT, and sends the Host header in HTTP_HOST – they do not have to match.

Does not add X-Forwarded-For or other standard headers

wsgiproxy.exactproxy.filter_paste_httpserver_proxy(app)
Maps the paste.httpserver proxy environment keys to SERVER_NAME and SERVER_PORT. This allows you to use paste.httpserver as a real HTTP proxy (wrapping proxy_exact_request with this middleware).
wsgiproxy.exactproxy.parse_headers(message)
Turn a Message object into a list of WSGI-style headers.

wsgiproxy.middleware – Accept serialized WSGI requests

These functions are used to sign and check requests:

wsgiproxy.signature.sign_request(environ, secret)
Add a X-WSGIProxy-Signature header to a request environment, based on the environment and an arbitrary number.
wsgiproxy.signature.check_request(environ, secret)
Checks the environments’ signature. If the signature is not correct, raises BadSignatureError. Removes the signature from the request.
exception wsgiproxy.signature.BadSignature
Exception raised by check_request

wsgiproxy.spawn – Spawn HTTP server subprocesses as Applications

WSGI application that dispatches all requests to a subprocess.

The subprocess is managed by this process, started on demand (at the time of the first request) and closed when this process is closed.

See SpawningApplication for more.

class wsgiproxy.spawn.SpawningApplication(start_script, cwd=None, script_env=None, spawned_port=None, idle_shutdown=None, logger=None)

A WSGI application that dispatches requests to a subprocess.

The subprocess is started with start_script. This must start the subprocess in the foreground. It should not start the subprocess with a shell script (unless you use exec) as this creates an intermediate process. The value may include __PORT__ which will be substituted with the port that the application should start on.

You can control how the subprocess starts with the cwd argument (the current working directory for the subprocess) and script_env (the environment it is run in).

If you give spawned_port that will be used; otherwise the server will look for a free port.

If you give idle_shutdown then the subprocess will be shut down after that many seconds of idle (when there are no requests). It will be started up again on the next request.

Note that the Host header will be preserved in the subrequest. REMOTE_ADDR is put in X-Forwarded-For, and the scheme is put into X-Forwarded-Scheme. The entire original path is requested, but SCRIPT_NAME is put into X-Script-Name.