wsgi_python_optimize n

wsgi_python_optimize 0

http, server, location

Directive sets the optimization level of the Python compiler.

This is equivalent to the -O option of the Python Interpreter.

wsgi_python_executable path

http, server, location

Directive sets the path to the python interpreter executable.

This value is used to find the Python run-time libraries relative to the interpreter executable.

wsgi_enable_subinterpreters on | off

wsgi_enable_subinterpreters off

http, server, location

Directive enables the use of sub interpreters.

When enabled, each WSGI application will be executed in a separate sub interpreter, unless wsgi_use_main_interpreter directive is used.

NOTE: some applications may have problems when executed inside a subinterpreter.

wsgi_pass_authorization on | off

wsgi_pass_authorization off

http, server, location

By default, as suggested by the CGI spec, mod_wsgi does not pass the Authorization header to the WSGI application.

Enable this directive if the WSGI application handles HTTP authentication.

wsgi_allow_ranges on | off

wsgi_allow_ranges off

http, server, location

Directive enables integrated support to partial HTTP requests, using the nginx range filter module.

NOTE: in the current version nginx supports ranges for single buffer responses only.

wsgi_script_reloading on | off

wsgi_script_reloading off

http, server, location

If enabled, mod_wsgi will check, at every request, if the WSGI script has been modified.

If the script has been modified, it will reload the application using the reload mechanism specified in the wsgi_reload_mechanism directive.

wsgi_reload_mechanism module | process

wsgi_script_reloading module

http, server, location

This directive specifies how to reload a WSGI application whose file has been modified.

When module mechanism is in use, mod_wsgi will remove the script module from the system modules dictionary and will reload it.

When process mechanism is in use, mod_wsgi will raise a QUIT signal. This signal will request Nginx to do a graceful shutdown of the process (see the Nginx documentation for detailed info). The current request is served using the old WSGI application, but mod_wsgi will add a Refresh: 0 header, so that clients that recognize this header can execute a new request to obtain the updated resource.

NOTE:

it is possible to reload a WSGI application by sending a HUP signal to the master process.

See http://wiki.codemongers.com/NginxCommandLine for more info.

WARNING: if the master process is not active, the Nginx process will be terminated.

wsgi_optimize_send_headers on | off

wsgi_optimize_send_headers off

http, server, location

Directive enables to optimize away content generation, when HTTP request does not requires a response body (as an example for HEAD request, or for a GET request when the client has a fresh cache of the resource entity).

For an effective use of this optimization, the WSGI application must return a generator and yield an empty string after having called start_response.

NOTE: WSGI spec explicitly requires that the headers must be sent when the first not empty string is yielded.

wsgi_output_buffering on | off

wsgi_output_buffering off

http, server, location

When output buffering is enabled, Nginx can buffer the data yielded by the WSGI application iterable.

This increments the performance, especially if the application yield small strings.

Note however that the WSGI spec recommend that the buffering should be done by the application and not by the gateway.

BUG: there seems to be problems when this directive is enabled.

wsgi_write_buffering on | off

wsgi_write_buffering off

http, server, location

This directive activates buffering of the write callable.

If buffering is activated, then mod_wsgi will store all the data written by the WSGI application in a buffer, assigned by directive wsgi_write_buffer_size.

The headers will be sent only when the WSGI application returns.

If the data can not all be placed in memory, then parts of it will be written to disk.

If buffering is switched off, then the data is synchronously transferred to client immediately.

NOTE: WSGI explicitly requires that the WSGI gateway must not buffer the data.

NOTE: sending data synchronously can have a severe impact on nginx performances.

wsgi_write_buffer_size buffer_size

wsgi_write_buffer_size 4k/8k

http, server, location

This directive controls the size of the buffer to use.

By default, the size of the buffer is equal to the size of page. Depending on platform this is either 4K or 8K.

wsgi_var variable value

http, server, location

Directive assigns the variable, which will be added to the environment dictionary passed to the WSGI application.

It is possible to use strings, nginx variables and their combination as values. Directives not set are inherited from the outer level.

NOTE:

variables defined using this directive are added to the environment dictionary after HTTP headers, so user can override these values.

It can be useful, as an example, to override HTTP_COOKIE with:

wsgi_var HTTP_COOKIE  $http_cookie;

since the $http_cookie variable combines multiple Cookie headers.

wsgi_use_main_interpreter on | off

wsgi_use_main_interpreter off

http, server, location

Directive enables the execution of the WSGI application using the main Python interpreter.

This directive is only used when wsgi_enable_subinterpreters directive is enabled.