1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
|
====================
WSGIScriptAliasMatch
====================
:Description: Maps a URL to a filesystem location and designates the target as a WSGI script.
:Syntax: ``WSGIScriptAliasMatch`` *regex file-path|directory-path* ``[`` *options* ``]``
:Context: server config, virtual host
This directive is similar to the WSGIScriptAlias directive, but makes use
of regular expressions, instead of simple prefix matching. The supplied
regular expression is matched against the URL-path, and if it matches, the
server will substitute any parenthesized matches into the given string and
use it as a filename.
For example, to map a URL to scripts contained within
a directory where the script files use the ``.wsgi`` extension, but it
is desired that the extension not appear in the URL, use::
WSGIScriptAliasMatch ^/wsgi-scripts/([^/]+) /web/wsgi-scripts/$1.wsgi
Note that you should only use WSGIScriptAliasMatch if you know what you are
doing. In most cases you should be using WSGIScriptAlias instead. If you
use WSGIScriptAliasMatch and don't do things the correct way, then you risk
modifying the value of SCRIPT_NAME as passed to the WSGI application and
this can stuff things up badly causing URL mapping to not work correctly
within the WSGI application or stuff up reconstruction of the full URL when
doing redirects. This is because the substitution of the matched sub
pattern from the left hand side back into the right hand side is often
critical.
If you think you need to use WSGIScriptAliasMatch, you probably don't
really. If you really really think you need it, then check on the mod_wsgi
mailing list about how to use it properly.
Options which can be supplied to the ``WSGIScriptAlias`` directive are:
**process-group=name**
Defines which process group the WSGI application will be executed
in. All WSGI applications within the same process group will execute
within the context of the same group of daemon processes.
If the name is set to be ``%{GLOBAL}`` the process group name will
be set to the empty string. Any WSGI applications in the global
process group will always be executed within the context of the
standard Apache child processes. Such WSGI applications will incur
the least runtime overhead, however, they will share the same
process space with other Apache modules such as PHP, as well as the
process being used to serve up static file content. Running WSGI
applications within the standard Apache child processes will also
mean the application will run as the user that Apache would normally
run as.
**application-group=name**
Defines which application group a WSGI application or set of WSGI
applications belongs to. All WSGI applications within the same
application group will execute within the context of the same Python
sub interpreter of the process handling the request.
If the name is set to be ``%{GLOBAL}`` the application group will be
set to the empty string. Any WSGI applications in the global
application group will always be executed within the context of the
first interpreter created by Python when it is initialised. Forcing
a WSGI application to run within the first interpreter can be
necessary when a third party C extension module for Python has used
the simplified threading API for manipulation of the Python GIL and
thus will not run correctly within any additional sub interpreters
created by Python.
If both ``process-group`` and ``application-group`` options are set, the
WSGI script file will be pre-loaded when the process it is to run in is
started, rather than being lazily loaded on the first request.
|
