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
72
73
74
75
76
77
78
79
80
81
82
83
84
85
|
====================
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 are using WSGIScriptAliasMatch to pass to a WSGI handler, and you
need to preserve the path. You can do the following::
WSGIScriptAlias /api /var/www/mysite.com/apache/django.wsgi/api
A more complicated example::
WSGIScriptAliasMatch "^/(admin|files|photologue)" /projects/Media/wsgi_handler.py/$1
This will keep the URL match from being stripped off the URL by the time it
reaches the WSGI application.
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, of the
process handling the request. 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, and
the WSGI script file doesn't include substiutions values to be supplied
from the matched URL pattern, 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.
|
