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
These functions are used to sign and check requests:
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.
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.