Skip to content

Commit 691a32d

Browse files
GrahamDumpletonGrahamDumpleton
committed
Merge branch 'develop' into feature/request-metrics
2 parents 2765518 + 0ff944b commit 691a32d

File tree

86 files changed

+9074
-161
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

86 files changed

+9074
-161
lines changed

‎configure.ac

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
dnl vim: set sw=4 expandtab :
22
dnl
3-
dnl Copyright 2007-2015 GRAHAM DUMPLETON
3+
dnl Copyright 2007-2016 GRAHAM DUMPLETON
44
dnl
55
dnl Licensed under the Apache License, Version 2.0 (the "License");
66
dnl you may not use this file except in compliance with the License.

‎docs/conf.py

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -41,7 +41,7 @@
4141

4242
# General information about the project.
4343
project = u'mod_wsgi'
44-
copyright = u'2007-2015, Graham Dumpleton'
44+
copyright = u'2007-2016, Graham Dumpleton'
4545

4646
# The version info for the project you're documenting, acts as replacement for
4747
# |version| and |release|, also used in various other places throughout the

‎docs/configuration-directives/WSGIAcceptMutex.rst

Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,21 @@
1+
===============
2+
WSGIAcceptMutex
3+
===============
4+
5+
:Description: Specify type of accept mutex used by daemon processes.
6+
:Syntax: ``WSGIAcceptMutex Default`` | *method*
7+
:Default: ``WSGIAcceptMutex Default``
8+
:Context: server config
9+
10+
The ``WSGIAcceptMutex`` directive sets the method that mod_wsgi will use to
11+
serialize multiple daemon processes in a process group accepting requests
12+
on a socket connection from the Apache child processes. If this directive
13+
is not defined then the same type of mutex mechanism as used by Apache for
14+
the main Apache child processes when accepting connections from a client
15+
will be used. If set the method types are the same as for the Apache
16+
`AcceptMutex`_ directive.
17+
18+
Note that the ``WSGIAcceptMutex`` directive and corresponding features are
19+
not available on Windows or when running Apache 1.3.
20+
21+
.. _AcceptMutex: http://httpd.apache.org/docs/2.4/mod/mpm_common.html#acceptmutex

‎docs/configuration-directives/WSGIAccessScript.rst

Lines changed: 31 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,31 @@
1+
================
2+
WSGIAccessScript
3+
================
4+
5+
:Description: Specify script implementing host access controls.
6+
:Syntax: ``WSGIAccessScript`` *path* [ *options* ]
7+
:Context: directory, .htaccess
8+
:Override: AuthConfig
9+
10+
The ``WSGIAccessScript`` directive provides a mechanism for implementing
11+
host access controls.
12+
13+
More detailed information on using the ``WSGIAccessScript`` directive
14+
can be found in :doc:`../user-guides/access-control-mechanisms`.
15+
16+
The options which can be supplied to the ``WSGIAccessScript`` directive are:
17+
18+
**application-group=name**
19+
20+
Specifies the name of the application group within the specified
21+
process for which the script file will be loaded.
22+
23+
If the ``application-group`` option is not supplied, the special value
24+
``%{GLOBAL}`` which denotes that the script file be loaded within the
25+
context of the first interpreter created by Python when it is
26+
initialised will be used. Otherwise, will be loaded into the
27+
interpreter for the specified application group.
28+
29+
Note that the script always runs in processes associated with embedded
30+
mode. It is not possible to delegate the script such that it is run within
31+
context of a daemon process.

‎docs/configuration-directives/WSGIApplicationGroup.rst

Lines changed: 106 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,106 @@
1+
====================
2+
WSGIApplicationGroup
3+
====================
4+
5+
:Description: Sets which application group WSGI application belongs to.
6+
:Syntax: ``WSGIApplicationGroup name``
7+
``WSGIApplicationGroup %{GLOBAL}``
8+
``WSGIApplicationGroup %{SERVER}``
9+
``WSGIApplicationGroup %{RESOURCE}``
10+
``WSGIApplicationGroup %{ENV:variable}``
11+
:Default: ``WSGIApplicationGroup %{RESOURCE}``
12+
:Context: server config, virtual host, directory
13+
14+
The ``WSGIApplicationGroup`` directive can be used to specify which
15+
application group a WSGI application or set of WSGI applications belongs
16+
to. All WSGI applications within the same application group will execute
17+
within the context of the same Python sub interpreter of the process
18+
handling the request.
19+
20+
The argument to the ``WSGIApplicationGroup`` can be either one of four
21+
special expanding variables or an explicit name of your own choosing.
22+
The meaning of the special variables are:
23+
24+
**%{GLOBAL}**
25+
26+
The application group name will be set to the empty string.
27+
28+
Any WSGI applications in the global application group will always be
29+
executed within the context of the first interpreter created by Python
30+
when it is initialised. Forcing a WSGI application to run within the
31+
first interpreter can be necessary when a third party C extension
32+
module for Python has used the simplified threading API for
33+
manipulation of the Python GIL and thus will not run correctly within
34+
any additional sub interpreters created by Python.
35+
36+
**%{SERVER}**
37+
38+
The application group name will be set to the server hostname. If the
39+
request arrived over a non standard HTTP/HTTPS port, the port number
40+
will be added as a suffix to the group name separated by a colon.
41+
42+
For example, if the virtual host ``www.example.com`` is handling
43+
requests on the standard HTTP port (80) and HTTPS port (443), a request
44+
arriving on either port would see the application group name being set
45+
to ``www.example.com``. If instead the virtual host was handling requests
46+
on port 8080, then the application group name would be set to
47+
``www.example.com:8080``.
48+
49+
**%{RESOURCE}**
50+
51+
The application group name will be set to the server hostname and port
52+
as for the ``%{SERVER}`` variable, to which the value of WSGI environment
53+
variable ``SCRIPT_NAME`` is appended separated by the file separator
54+
character.
55+
56+
For example, if the virtual host ``www.example.com`` was handling
57+
requests on port 8080 and the URL-path which mapped to the WSGI
58+
application was::
59+
60+
http://www.example.com/wsgi-scripts/foo
61+
62+
then the application group name would be set to::
63+
64+
www.example.com:8080|/wsgi-scripts/foo
65+
66+
The effect of using the ``%{RESOURCE}`` variable expansion is for each
67+
application on any server to be isolated from all others by being
68+
mapped to its own Python sub interpreter.
69+
70+
**%{ENV:variable}**
71+
72+
The application group name will be set to the value of the named
73+
environment variable. The environment variable is looked-up via the
74+
internal Apache notes and subprocess environment data structures and
75+
(if not found there) via ``getenv()`` from the Apache server process.
76+
77+
In an Apache configuration file, environment variables accessible using
78+
the ``%{ENV}`` variable reference can be setup by using directives such as
79+
`SetEnv`_ and `RewriteRule`_.
80+
81+
For example, to group all WSGI scripts for a specific user when using
82+
`mod_userdir`_ within the same application group, the following could be
83+
used::
84+
85+
RewriteEngine On
86+
RewriteCond %{REQUEST_URI} ^/~([^/]+)
87+
RewriteRule . - [E=APPLICATION_GROUP:~%1]
88+
89+
<Directory /home/*/public_html/wsgi-scripts/>
90+
Options ExecCGI
91+
SetHandler wsgi-script
92+
WSGIApplicationGroup %{ENV:APPLICATION_GROUP}
93+
</Directory>
94+
95+
Note that in embedded mode or a multi process daemon process group, there
96+
will be an instance of the named sub interpreter in each process. Thus the
97+
directive only ensures that request is handled in the named sub interpreter
98+
within the process that handles the request. If you need to ensure that
99+
requests for a specific user always go back to the exact same sub interpreter,
100+
then you will need to use a daemon process group with only a single process,
101+
or implement sticky session mechanism across a number of single process
102+
daemon process groups.
103+
104+
.. _SetEnv: http://httpd.apache.org/docs/2.2/mod/mod_env.html#setenv
105+
.. _RewriteRule: http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewriterule
106+
.. _mod_userdir: http://httpd.apache.org/docs/2.2/mod/mod_userdir.html

‎docs/configuration-directives/WSGIAuthGroupScript.rst

Lines changed: 31 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,31 @@
1+
===================
2+
WSGIAuthGroupScript
3+
===================
4+
5+
:Description: Specify script implementing group authorisation.
6+
:Syntax: ``WSGIAuthGroupScript`` *path* [ *options* ]
7+
:Context: directory, .htaccess
8+
:Override: AuthConfig
9+
10+
The ``WSGIAuthGroupScript`` directive provides a mechanism for implementing
11+
group authorisation using the Apache ``Require`` directive.
12+
13+
More detailed information on using the ``WSGIAuthGroupScript`` directive
14+
can be found in :doc:`../user-guides/access-control-mechanisms`.
15+
16+
The options which can be supplied to the ``WSGIAuthGroupScript`` directive are:
17+
18+
**application-group=name**
19+
20+
Specifies the name of the application group within the specified
21+
process for which the script file will be loaded.
22+
23+
If the ``application-group`` option is not supplied, the special value
24+
``%{GLOBAL}`` which denotes that the script file be loaded within the
25+
context of the first interpreter created by Python when it is
26+
initialised will be used. Otherwise, will be loaded into the
27+
interpreter for the specified application group.
28+
29+
Note that the script always runs in processes associated with embedded
30+
mode. It is not possible to delegate the script such that it is run within
31+
context of a daemon process.

‎docs/configuration-directives/WSGIAuthUserScript.rst

Lines changed: 40 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,40 @@
1+
==================
2+
WSGIAuthUserScript
3+
==================
4+
5+
:Description: Specify script implementing an authentication provider.
6+
:Syntax: ``WSGIAuthUserScript`` *path* [ *options* ]
7+
:Context: directory, .htaccess
8+
:Override: AuthConfig
9+
10+
The WSGIAuthUserScript directive can be used to specify a script which
11+
implements an Apache authentication provider.
12+
13+
Such an authentication provider can be used where you want Apache to worry
14+
about the handshaking related to HTTP Basic and Digest authentication and
15+
you only wish to deal with supplying the user credentials for authenticating
16+
the user.
17+
18+
If using at least Apache 2.2, other Apache modules implementing custom
19+
authentication mechanisms can also make use of the authentication provider
20+
if they are using the corresponding Apache C API for accessing them.
21+
22+
More detailed information on using the WSGIAuthUserScript directive can be
23+
found in :doc:`../user-guides/access-control-mechanisms`.
24+
25+
The options which can be supplied to the WSGIAuthUserScript directive are:
26+
27+
**application-group=name**
28+
Specifies the name of the application group within the specified
29+
process for which the script file will be loaded.
30+
31+
If the 'application-group' option is not supplied, the special value
32+
'%{GLOBAL}' which denotes that the script file be loaded within the
33+
context of the first interpreter created by Python when it is
34+
initialised will be used. Otherwise, will be loaded into the
35+
interpreter for the specified application group.
36+
37+
Note that the script always runs in processes associated with embedded
38+
mode. It is not possible to delegate the script such that it is run within
39+
context of a daemon process.
40+

‎docs/configuration-directives/WSGICallableObject.rst

Lines changed: 29 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,29 @@
1+
==================
2+
WSGICallableObject
3+
==================
4+
5+
:Description: Sets the name of the WSGI application callable.
6+
:Syntax: ``WSGICallableObject`` *name*
7+
``WSGICallableObject %{ENV:variable}``
8+
:Default: ``WSGICallableObject application``
9+
:Context: server config, virtual host, directory, .htaccess
10+
:Override: ``FileInfo``
11+
12+
The WSGICallableObject directive can be used to override the name of the
13+
Python callable object in the script file which is used as the entry point
14+
into the WSGI application.
15+
16+
When ``%{ENV}`` is being used, the environment variable is looked-up via the
17+
internal Apache notes and subprocess environment data structures and (if
18+
not found there) via getenv() from the Apache server process.
19+
20+
In an Apache configuration file, environment variables accessible using
21+
the ``%{ENV}`` variable reference can be setup by using directives such as
22+
`SetEnv`_ and `RewriteRule`_.
23+
24+
Note that the name of the callable object must be an object present at
25+
global scope within the WSGI script file. It is not possible to use a dotted
26+
path to refer to a sub object of a module imported by the WSGI script file.
27+
28+
.. _SetEnv: http://httpd.apache.org/docs/2.2/mod/mod_env.html#setenv
29+
.. _RewriteRule: http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewriterule

‎docs/configuration-directives/WSGICaseSensitivity.rst

Lines changed: 23 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,23 @@
1+
===================
2+
WSGICaseSensitivity
3+
===================
4+
5+
:Description: Define whether file system is case sensitive.
6+
:Syntax: ``WSGICaseSensitivity On|Off``
7+
:Context: server config
8+
9+
When mod_wsgi is used on the Windows and MacOS X platforms, it will assume
10+
that the filesystem in use is case insensitive. This is necessary to ensure
11+
that the module caching system works correctly and only one module is
12+
retained in memory where paths with different case are used to identify the
13+
same script file. On other platforms it will always be assumed that a case
14+
sensitive file system is used.
15+
16+
The WSGICaseSensitivity directive can be used explicitly to specify for a
17+
particular WSGI application whether the file system the script file is
18+
stored in is case sensitive or not, thus overriding the default for any
19+
platform. A value of On indicates that the filesystem is case sensitive.
20+
21+
Because it is set in the main server config it will apply to the whole
22+
site. All paths therefore would need to be located in a filesystem with the
23+
same case convention.

0 commit comments

Comments
 (0)