Script 'mail_helper' called by obssrc
Hello community,
here is the log from the commit of package apache2-mod_wsgi for
openSUSE:Factory checked in at 2022-11-24 12:23:34
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Factory/apache2-mod_wsgi (Old)
and /work/SRC/openSUSE:Factory/.apache2-mod_wsgi.new.1597 (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "apache2-mod_wsgi"
Thu Nov 24 12:23:34 2022 rev:33 rq:1037608 version:4.9.4
Changes:
--------
--- /work/SRC/openSUSE:Factory/apache2-mod_wsgi/apache2-mod_wsgi.changes
2022-06-23 10:25:47.899839606 +0200
+++
/work/SRC/openSUSE:Factory/.apache2-mod_wsgi.new.1597/apache2-mod_wsgi.changes
2022-11-24 12:23:42.189478241 +0100
@@ -1,0 +2,17 @@
+Wed Nov 23 13:12:00 UTC 2022 - Dominique Leuenberger <dims...@opensuse.org>
+
+- Update to version 4.9.4:
+ + Apache 2.4.54 changed the default value for LimitRequestBody
+ from 0, which indicates there is no limit, to 1Gi. If the
+ Apache configuration supplied with a distribution wasnât
+ explicitly setting LimitRequestBody to 0 at global server scope
+ for the purposes of documenting the default, and it was
+ actually relying on the compiled in default, then when using
+ mod_wsgi daemon mode, if a request body size greater than 1Gi
+ was encountered the mod_wsgi daemon mode process would crash.
+ + Fix ability to build mod_wsgi against Apache 2.2. Do note that
+ in general only recent versions of Apache 2.4 are supported
+- Changes from version 4.9.3 (CVE-2022-2255, boo#1201634):
+ * See
https://modwsgi.readthedocs.io/en/latest/release-notes/version-4.9.3.html
+
+-------------------------------------------------------------------
Old:
----
mod_wsgi-4.9.2.tar.gz
New:
----
mod_wsgi-4.9.4.tar.gz
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Other differences:
------------------
++++++ apache2-mod_wsgi.spec ++++++
--- /var/tmp/diff_new_pack.4XflSy/_old 2022-11-24 12:23:42.777481978 +0100
+++ /var/tmp/diff_new_pack.4XflSy/_new 2022-11-24 12:23:42.781482004 +0100
@@ -27,7 +27,7 @@
BuildRequires: httpd-devel
%endif
Name: apache2-mod_wsgi
-Version: 4.9.2
+Version: 4.9.4
Release: 0
Summary: A WSGI interface for Python3 web applications in Apache
License: Apache-2.0
++++++ mod_wsgi-4.9.2.tar.gz -> mod_wsgi-4.9.4.tar.gz ++++++
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/mod_wsgi-4.9.2/README-standalone.rst
new/mod_wsgi-4.9.4/README-standalone.rst
--- old/mod_wsgi-4.9.2/README-standalone.rst 2022-05-31 02:45:32.000000000
+0200
+++ new/mod_wsgi-4.9.4/README-standalone.rst 2022-09-12 03:56:13.000000000
+0200
@@ -10,8 +10,8 @@
version of Apache pre-installed on your target system, and if you don't,
installation of the package will fail.
-If you are on a UNIX like system (Linux, macOS) and need a version of
-Apache to be installed for you, you can use the ``mod_wsgi-standalone``
+If you are on a UNIX like system (Linux) and need a version of Apache
+to be installed for you, you can use the ``mod_wsgi-standalone``
package on PyPi instead. When installing the ``mod_wsgi-standalone``
package it will first trigger the installation of the ``mod_wsgi-httpd``
package, which will result in a version of Apache being installed as
@@ -19,12 +19,21 @@
installed, with it using the version of Apache installed by the
``mod_wsgi-httpd`` package rather than any system package for Apache.
-Note that this method of installation is only suitable for where you want
-to use ``mod_wsgi-express``. It cannot be used to build mod_wsgi for use
-with your system Apache installation. This installation method will also
-not work on Windows.
+This method of installation is only suitable for where you want to use
+``mod_wsgi-express``. It cannot be used to build mod_wsgi for use with
+your system Apache installation. This installation method will not
+work on Windows, and also currently fails on macOS because the Apache
+Runtime (APR) library, has not been updated to latest macOS versions.
When installing mod_wsgi using this method, except that you will install
the ``mod_wsgi-standalone`` package instead of the ``mod_wsgi`` package,
you should follow installation and usage instructions outlined on the
PyPi page for the ``mod_wsgi`` package.
+
+**NOTE: Although this package may allow you to install a standalone Apache
+version, it is only really recommended that you use this package if you
+have absolutely no other choice for getting the Apache httpd server
+installed. Always use the Apache httpd server supplied with the operating
+system if you can. Building this package if you do choose to do so, will
+take some time. So if you you think the install is hanging, it is probably
+still busy compiling everything.**
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/mod_wsgi-4.9.2/docs/configuration-directives/WSGITrustedProxies.rst
new/mod_wsgi-4.9.4/docs/configuration-directives/WSGITrustedProxies.rst
--- old/mod_wsgi-4.9.2/docs/configuration-directives/WSGITrustedProxies.rst
1970-01-01 01:00:00.000000000 +0100
+++ new/mod_wsgi-4.9.4/docs/configuration-directives/WSGITrustedProxies.rst
2022-09-12 03:56:13.000000000 +0200
@@ -0,0 +1,15 @@
+==================
+WSGITrustedProxies
+==================
+
+:Description: Specify a list of trusted proxies.
+:Syntax: ``WSGITrustedProxies`` *ipaddr|(ipaddr-1 ipaddr-2 ...)*
+:Context: server config, virtual host, directory, .htaccess
+:Override: ``FileInfo``
+
+Used to specify a list of IP addresses for proxies placed in front of the
+Apache instance which are trusted.
+
+This directive only has effect when used in conjunction with the
+``WSGITrustedProxyHeaders`` directive. For more details see the documentation
+for the ``WSGITrustedProxyHeaders`` directive.
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/mod_wsgi-4.9.2/docs/configuration-directives/WSGITrustedProxyHeaders.rst
new/mod_wsgi-4.9.4/docs/configuration-directives/WSGITrustedProxyHeaders.rst
---
old/mod_wsgi-4.9.2/docs/configuration-directives/WSGITrustedProxyHeaders.rst
1970-01-01 01:00:00.000000000 +0100
+++
new/mod_wsgi-4.9.4/docs/configuration-directives/WSGITrustedProxyHeaders.rst
2022-09-12 03:56:13.000000000 +0200
@@ -0,0 +1,231 @@
+=======================
+WSGITrustedProxyHeaders
+=======================
+
+:Description: Specify a list of trusted proxy headers.
+:Syntax: ``WSGITrustedProxyHeaders`` *header|(header-1 header-2 ...)*
+:Context: server config, virtual host, directory, .htaccess
+:Override: ``FileInfo``
+
+When trusted proxies are designated, this is used to specify the headers
+which are used to convey information from a proxy to a web server behind the
+proxy that are to be trusted.
+
+The IP addresses of the proxies to be trusted should be specified using the
+``WSGITrustedProxies`` directive.
+
+As there are multiple conventions for what headers are used to convey
+information from the proxy to the web server you need to specify the specific
+header from a supported list of headers for a particular purpose that you want
+to trust using the ``WSGITrustedProxyHeaders`` directive.
+
+When a request is then received from a trusted proxy, only the header from
+the set of headers for that particular purpose is passed through to the WSGI
+application and all others will be dropped. If a request was instead from an
+IP address which isn't a trusted proxy, then all headers in that set of headers
+will be dropped and not passed through.
+
+Depending on the purpose of the header, modifications will be made to other
+special variables passed through to the WSGI application. It is these other
+variables which is what the WSGI application should consult and the original
+header should never be consulted, with it only being provided as an indication
+of which header was used to set the special variable.
+
+The different sets of supported headers used by proxies are as follows.
+
+For passing through the IP address of the remote HTTP client the supported
+headers are:
+
+* X-Forwarded-For
+* X-Client-IP
+* X-Real-IP
+
+You should select only one of these headers as the authoritative source for
+the IP address of the remote HTTP client as sent by the proxy. Never select
+multiple headers because if you do which will be used is indeterminate.
+
+The de-facto standard for this type of header is ``X-Forwarded-For`` and it
+is recommended that it be used if your proxy supports it.
+
+The configuration might therefore be::
+
+ WSGITrustedProxies 1.2.3.4
+ WSGITrustedProxyHeaders X-Forwarded-For
+
+With this configuration, when a request is received from the trusted proxy only
+the ``X-Forwarded-For`` header will be passed through to the WSGI application.
+This will be done following CGI convention as used by WSGI, namely in the
+``HTTP_X_FORWARDED_FOR`` variable.
+
+For this set of headers, the ``REMOTE_ADDR`` CGI variable as used by WSGI will
+be modified and set to the IP address of the remote HTTP client. A WSGI
+application in this case should always use ``REMOTE_ADDR`` and never consult
+the original header files.
+
+For passing through the protocol of the original request received by the
+trusted proxy the supported headers are:
+
+* X-Forwarded-HTTPS
+* X-Forwarded-Proto
+* X-Forwarded-Scheme
+* X-Forwarded-SSL
+* X-HTTPS
+* X-Scheme
+
+You should select only one of these headers as the authoritative source for
what
+protocol was used by the remote HTTP client as sent by the proxy. Never select
+multiple headers because if you do which will be used is indeterminate.
+
+The de-facto standard for this type of header is ``X-Forwarded-Proto`` and it
+is recommended that it be used if your proxy supports it.
+
+The configuration might therefore be::
+
+ WSGITrustedProxies 1.2.3.4
+ WSGITrustedProxyHeaders X-Forwarded-Proto
+
+With this configuration, when a request is received from the trusted proxy only
+the ``X-Forwarded-Proto`` header will be passed through to the WSGI
application.
+This will be done following CGI convention as used by WSGI, namely in the
+``HTTP_X_FORWARDED_PROTO`` variable.
+
+For this set of headers, the ``wsgi.url_scheme`` variable passed to the WSGI
+application will be modified to indicate whether the original request used the
+``https`` protocol. Note that although it is a convention when using CGI
+scripts with Apache, the mod_wsgi module removes the ``HTTPS`` variable from
+the set of variables passed to the WSGI application. You should always use
+the ``wsgi.url_scheme`` variable in a WSGI application.
+
+For passing through the host name targeted by the original request received by
+the trusted proxy the supported headers are:
+
+* X-Forwarded-Host
+* X-Host
+
+You should select only one of these headers as the authoritative source for the
+host targeted by the original request as sent by the proxy. Never select
+multiple headers because if you do which will be used is indeterminate.
+
+The de-facto standard for this type of header is ``X-Forwarded-Host`` and it
+is recommended that it be used if your proxy supports it.
+
+The configuration might therefore be::
+
+ WSGITrustedProxies 1.2.3.4
+ WSGITrustedProxyHeaders X-Forwarded-Host
+
+With this configuration, when a request is received from the trusted proxy only
+the ``X-Forwarded-Host`` header will be passed through to the WSGI application.
+This will be done following CGI convention as used by WSGI, namely in the
+``HTTP_X_FORWARDED_HOST`` variable.
+
+For this set of headers, the ``HTTP_HOST`` variable passed to the WSGI
+application will be overridden with the value from the header supplied by the
+proxy. That is, the value from the proxy for the original request will even
+override any explicit ``Host`` header supplied in the request from the proxy,
+which in normal cases would be the host of the web server. A WSGI application
+should always consult the ``HTTP_HOST`` variable and not the separate header
+supplied by the proxy.
+
+For passing through the port targeted by the original request received by the
+trusted proxy, the only supported header is:
+
+* X-Forwarded-Port
+
+Although it is the only supported header, you still must select if as a trusted
+header to have it processed in the same way as other trusted headers.
+
+The configuration might therefore be::
+
+ WSGITrustedProxies 1.2.3.4
+ WSGITrustedProxyHeaders X-Forwarded-Port
+
+With this configuration, when a request is received from the trusted proxy only
+the ``X-Forwarded-Port`` header will be passed through to the WSGI application.
+This will be done following CGI convention as used by WSGI, namely in the
+``HTTP_X_FORWARDED_PORT`` variable.
+
+For this header, the ``SERVER_PORT`` variable passed to the WSGI application
+will be overridden with the value from the header supplied by the proxy. A WSGI
+application should always consult the ``SERVER_PORT`` variable and not the
+separate header supplied by the proxy.
+
+For passing through the host name of any proxy, to use in overriding the host
+name of the web server, the only supported header is:
+
+* X-Forwarded-Server
+
+Although it is the only supported header, you still must select if as a trusted
+header to have it processed in the same way as other trusted headers.
+
+The configuration might therefore be::
+
+ WSGITrustedProxies 1.2.3.4
+ WSGITrustedProxyHeaders X-Forwarded-Server
+
+With this configuration, when a request is received from the trusted proxy only
+the ``X-Forwarded-Server`` header will be passed through to the WSGI
application.
+This will be done following CGI convention as used by WSGI, namely in the
+``HTTP_X_FORWARDED_SERVER`` variable.
+
+For this header, the ``SERVER_NAME`` variable passed to the WSGI application
+will be overridden with the value from the header supplied by the proxy. A WSGI
+application should always consult the ``SERVER_NAME`` variable and not the
+separate header supplied by the proxy.
+
+For passing through the apparent URL sub path of a web application, as mapped
+by the trusted proxy, the supported headers are:
+
+* X-Script-Name
+* X-Forwarded-Script-Name
+
+You should select only one of these headers as the authoritative source for the
+host targeted by the original request as sent by the proxy. Never select
+multiple headers because if you do which will be used is indeterminate.
+
+The configuration might therefore be::
+
+ WSGITrustedProxies 1.2.3.4
+ WSGITrustedProxyHeaders X-Script-Name
+
+With this configuration, when a request is received from the trusted proxy only
+the ``X-Script-Name`` header will be passed through to the WSGI application.
+This will be done following CGI convention as used by WSGI, namely in the
+``HTTP_X_SCRIPT_NAME`` variable.
+
+For this header, the ``SCRIPT_NAME`` variable passed to the WSGI application
+will be overridden with the value from the header supplied by the proxy. A WSGI
+application should always consult the ``SCRIPT_NAME`` variable and not the
+separate header supplied by the proxy.
+
+Examples above show using a single header of a specific purpose at one time.
+When you need to trust multiple headers for different purposes, you can list
+them separated by spaces using one instance of ``WSGITrustedProxyHeaders``::
+
+ WSGITrustedProxyHeaders X-Forwarded-For X-Forwarded-Host X-Forwarded-Port
+
+or in separate directives::
+
+ WSGITrustedProxyHeaders X-Forwarded-For
+ WSGITrustedProxyHeaders X-Forwarded-Host
+ WSGITrustedProxyHeaders X-Forwarded-Port
+
+As already highlighted you should only list one header for a specific purpose
+when there are multiple conventions for what header to use. Which you use will
+depend on the configuration of your proxy. You should only trust headers which
+are always set by the proxy, never trust headers which are optionally set by
+proxies because if not overridden by a proxy, a remote client could still
+supply the header.
+
+Also remember that in general you should not consult the proxied headers
+themselves, but instead consult the special variables set from those headers
+which are passed to the WSGI application and which are defined as being special
+to WSGI. As illustration of how such special variables are used, consider
+for example the notes in the WSGI specification around URL reconstruction.
+
+* https://peps.python.org/pep-3333/#url-reconstruction
+
+Finally, if using this feature to trust proxies and designated headers, do not
+enable in any WSGI framework or application separate functionality it may have
+for also processing the proxy headers. You should only rely on what mod_wsgi
+has done to update variables special to WSGI.
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/mod_wsgi-4.9.2/docs/configuration.rst
new/mod_wsgi-4.9.4/docs/configuration.rst
--- old/mod_wsgi-4.9.2/docs/configuration.rst 2022-05-31 02:45:32.000000000
+0200
+++ new/mod_wsgi-4.9.4/docs/configuration.rst 2022-09-12 03:56:13.000000000
+0200
@@ -31,3 +31,5 @@
configuration-directives/WSGIScriptAliasMatch
configuration-directives/WSGIScriptReloading
configuration-directives/WSGISocketPrefix
+ configuration-directives/WSGITrustedProxies
+ configuration-directives/WSGITrustedProxyHeaders
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/mod_wsgi-4.9.2/docs/release-notes/version-4.9.3.rst
new/mod_wsgi-4.9.4/docs/release-notes/version-4.9.3.rst
--- old/mod_wsgi-4.9.2/docs/release-notes/version-4.9.3.rst 1970-01-01
01:00:00.000000000 +0100
+++ new/mod_wsgi-4.9.4/docs/release-notes/version-4.9.3.rst 2022-09-12
03:56:13.000000000 +0200
@@ -0,0 +1,95 @@
+=============
+Version 4.9.3
+=============
+
+Version 4.9.3 of mod_wsgi can be obtained from:
+
+ https://codeload.github.com/GrahamDumpleton/mod_wsgi/tar.gz/4.9.3
+
+Bugs Fixed
+----------
+
+* When using ``WSGITrustedProxies`` and ``WSGITrustedProxyHeaders`` in the
+ Apache configuration, or ``--trust-proxy`` and ``--trust-proxy-header``
+ options with ``mod_wsgi-express``, if you trusted the ``X-Client-IP``
+ header and a request was received from an untrusted client, the header
+ was not being correctly removed from the set of headers passed through to
+ the WSGI application.
+
+ This only occurred with the ``X-Client-IP`` header and the same problem was
+ not present if trusting the ``X-Real-IP`` or ``X-Forwarded-For`` headers.
+
+ The purpose of this feature for trusting a front end proxy was in this
+ case for the headers:
+
+ * ``X-Client-IP``
+ * ``X-Real-IP``
+ * ``X-Forwarded-For``
+
+ and was designed to allow the value of ``REMOTE_ADDR`` passed to the WSGI
+ application to be rewritten to the IP address that a trusted proxy said
+ was the real remote address of the client.
+
+ In other words, if a request was received from a proxy the IP address
+ of which was trusted, ``REMOTE_ADDR`` would be set to the value of the
+ single designated header out of those listed above which was to be
+ trusted.
+
+ In the case where the proxy was trusted, in addition to ``REMOTE_ADDR``
+ being rewritten, only the trusted header would be passed through. That is,
+ if ``X-Real-IP`` was the trusted header, then ``HTTP_X_REAL_IP`` would
+ be passed to the WSGI application, but ``HTTP_X_CLIENT_IP`` and
+ ``HTTP_X_FORWARDED_FOR`` would be dropped if corresponding headers had
+ also been supplied. That the header used to rewrite ``REMOTE_ADDR`` was
+ passed through still was only intended for the purpose of documenting
+ where the value of ``REMOTE_ADDR`` came from. A WSGI application when
+ relying on this feature should only ever use the value of ``REMOTE_ADDR``
+ and should ignore the header passed through.
+
+ The behaviour as described was therefore based on a WSGI application
+ not at the same time enabling any WSGI or web framework middleware to
+ try and process any proxy headers a second time and ``REMOTE_ADDR``
+ should be the single source of truth. Albeit the headers which were
+ passed through should have resulted in the same result for ``REMOTE_ADDR``
+ if the proxy headers were processed a second time.
+
+ Now in the case of the client a request was received from not being a
+ trusted proxy, then ``REMOTE_ADDR`` would not be rewritten, and would
+ be left as the IP of the client, and none of the headers listed above
+ were supposed to be passed through.
+
+ That ``REMOTE_ADDR`` is not rewritten is implemented correctly when the
+ client is not a trusted proxy, but of the three headers listed above,
+ ``HTTP_X_CLIENT_ID`` was not being dropped if the corresponding header
+ was supplied.
+
+ If the WSGI application followed best practice and only relied on the
+ value of ``REMOTE_ADDR`` as the source of truth for the remote client
+ address, then that ``HTTP_X_CLIENT_ID`` was not being dropped should
+ pose no security risk. There would however be a problem if a WSGI
+ application was still enabling a WSGI or web framework specific middleware
+ to process the proxy headers a second time even though not required. In this
+ case, the middleware used by the WSGI application may still trust the
+ ``X-Client-IP`` header and rewrite ``REMOTE_ADDR`` allowing a malicious
+ client to pretend to have a different IP address.
+
+ In addition to the WSGI application having redundant checks for the proxy
+ headers, to take advantage of this, a client would also need direct access
+ to the Apache/mod_wsgi server instance.
+
+ In the case that only clients on your private network behind your proxy
+ could access the Apache/mod_wsgi server instance, that would imply any
+ malicious actor already had access to your private network and had access
+ to hosts in that private network or could attach their own device to that
+ private network.
+
+ In the case where your Apache/mod_wsgi server instance could be accessed
+ from the same external networks as a proxy forwarding requests to it, such
+ as may occur if making use of a CDN proxy cache, a client would still need
+ to know the direct address used by the Apache/mod_wsgi server instance.
+
+ Note that only one proxy header for designating the IP of a client should
+ ever be trusted. If you trust more than one, then which will be used if
+ both are present is undefined as it is dependent on the order that Apache
+ processes headers. This hasn't changed and as before to avoid ambiguity you
+ should only trust one of the proxy headers recognised for this purpose.
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/mod_wsgi-4.9.2/docs/release-notes/version-4.9.4.rst
new/mod_wsgi-4.9.4/docs/release-notes/version-4.9.4.rst
--- old/mod_wsgi-4.9.2/docs/release-notes/version-4.9.4.rst 1970-01-01
01:00:00.000000000 +0100
+++ new/mod_wsgi-4.9.4/docs/release-notes/version-4.9.4.rst 2022-09-12
03:56:13.000000000 +0200
@@ -0,0 +1,21 @@
+=============
+Version 4.9.4
+=============
+
+Version 4.9.4 of mod_wsgi can be obtained from:
+
+ https://codeload.github.com/GrahamDumpleton/mod_wsgi/tar.gz/4.9.4
+
+Bugs Fixed
+----------
+
+* Apache 2.4.54 changed the default value for ``LimitRequestBody`` from 0,
which
+ indicates there is no limit, to 1Gi. If the Apache configuration supplied
with
+ a distribution wasn't explicitly setting ``LimitRequestBody`` to 0 at global
+ server scope for the purposes of documenting the default, and it was actually
+ relying on the compiled in default, then when using mod_wsgi daemon mode, if
a
+ request body size greater than 1Gi was encountered the mod_wsgi daemon mode
+ process would crash.
+
+* Fix ability to build mod_wsgi against Apache 2.2. Do note that in general
only
+ recent versions of Apache 2.4 are supported
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/mod_wsgi-4.9.2/docs/release-notes.rst
new/mod_wsgi-4.9.4/docs/release-notes.rst
--- old/mod_wsgi-4.9.2/docs/release-notes.rst 2022-05-31 02:45:32.000000000
+0200
+++ new/mod_wsgi-4.9.4/docs/release-notes.rst 2022-09-12 03:56:13.000000000
+0200
@@ -5,6 +5,8 @@
.. toctree::
:maxdepth: 2
+ release-notes/version-4.9.4
+ release-notes/version-4.9.3
release-notes/version-4.9.2
release-notes/version-4.9.1
release-notes/version-4.9.0
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore'
old/mod_wsgi-4.9.2/docs/user-guides/debugging-techniques.rst
new/mod_wsgi-4.9.4/docs/user-guides/debugging-techniques.rst
--- old/mod_wsgi-4.9.2/docs/user-guides/debugging-techniques.rst
2022-05-31 02:45:32.000000000 +0200
+++ new/mod_wsgi-4.9.4/docs/user-guides/debugging-techniques.rst
2022-09-12 03:56:13.000000000 +0200
@@ -76,13 +76,13 @@
status = '200 OK'
output = b'Hello World!'
- print("application debug #1", file=environ['wsgi.errors']))
+ print("application debug #1", file=environ['wsgi.errors'])
response_headers = [('Content-type', 'text/plain'),
('Content-Length', str(len(output)))]
start_response(status, response_headers)
- print("application debug #2", file=environ['wsgi.errors']))
+ print("application debug #2", file=environ['wsgi.errors'])
return [output]
@@ -95,7 +95,7 @@
Alternatively, always use `print` as a statement rather than a function::
- print >> environ['wsgi.errors']), "application debug #N"
+ print >> environ['wsgi.errors'], "application debug #N"
If 'wsgi.errors' is not available to the code which needs to output log
messages, then it should explicitly direct output from 'print'
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/mod_wsgi-4.9.2/pyproject.toml.in
new/mod_wsgi-4.9.4/pyproject.toml.in
--- old/mod_wsgi-4.9.2/pyproject.toml.in 2022-05-31 02:45:32.000000000
+0200
+++ new/mod_wsgi-4.9.4/pyproject.toml.in 2022-09-12 03:56:13.000000000
+0200
@@ -1,3 +1,3 @@
[build-system]
-requires = ["setuptools>=40.8.0", "wheel", "mod_wsgi-httpd==2.4.48.1"]
+requires = ["setuptools>=40.8.0", "wheel", "mod_wsgi-httpd==2.4.54.1"]
build-backend = "setuptools.build_meta:__legacy__"
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/mod_wsgi-4.9.2/setup.py new/mod_wsgi-4.9.4/setup.py
--- old/mod_wsgi-4.9.2/setup.py 2022-05-31 02:45:32.000000000 +0200
+++ new/mod_wsgi-4.9.4/setup.py 2022-09-12 03:56:13.000000000 +0200
@@ -466,5 +466,5 @@
entry_points = { 'console_scripts':
['mod_wsgi-express = mod_wsgi.server:main'],},
zip_safe = False,
- install_requires = standalone and ['mod_wsgi-httpd==2.4.48.1'] or [],
+ install_requires = standalone and ['mod_wsgi-httpd==2.4.54.1'] or [],
)
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/mod_wsgi-4.9.2/src/server/mod_wsgi.c
new/mod_wsgi-4.9.4/src/server/mod_wsgi.c
--- old/mod_wsgi-4.9.2/src/server/mod_wsgi.c 2022-05-31 02:45:32.000000000
+0200
+++ new/mod_wsgi-4.9.4/src/server/mod_wsgi.c 2022-09-12 03:56:13.000000000
+0200
@@ -12597,6 +12597,9 @@
/* Output status line. */
+ if (!r->status_line)
+ r->status_line = ap_get_status_line(r->status);
+
vec1[0].iov_base = (void *)"Status:";
vec1[0].iov_len = strlen("Status:");
vec1[1].iov_base = (void *)" ";
@@ -12710,6 +12713,7 @@
apr_bucket_brigade *bb;
core_request_config *req_cfg;
+ core_dir_config *d;
ap_filter_t *current = NULL;
ap_filter_t *next = NULL;
@@ -12901,6 +12905,23 @@
r->per_dir_config = r->server->lookup_defaults;
+ /*
+ * Try and ensure that request body limit in daemon mode process
+ * is unlimited as Apache 2.4.54 changed rules for limit and if
+ * unset is now overridden by HTTP filters to be 1GiB rather than
+ * unlimited. This is required since we populate configuration
+ * from the base server config only so setting unlimited in a more
+ * specific context such as a virtual host wouldn't be visible.
+ * Note that setting this to unlimited in the daemon mode process
+ * is okay as the request limit body is checked in the Apache
+ * child process before request is proxied specifically to avoid
+ * unecessarily passing the content across to the daemon process.
+ */
+
+ d = (core_dir_config *)ap_get_core_module_config(r->per_dir_config);
+
+ d->limit_req_body = 0;
+
r->sent_bodyct = 0;
r->read_length = 0;
@@ -14055,6 +14076,7 @@
name = ((const char**)trusted_proxy_headers->elts)[i];
if (!strcmp(name, "HTTP_X_FORWARDED_FOR") ||
+ !strcmp(name, "HTTP_X_CLIENT_IP") ||
!strcmp(name, "HTTP_X_REAL_IP")) {
match_client_header = 1;
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/mod_wsgi-4.9.2/src/server/wsgi_apache.c
new/mod_wsgi-4.9.4/src/server/wsgi_apache.c
--- old/mod_wsgi-4.9.2/src/server/wsgi_apache.c 2022-05-31 02:45:32.000000000
+0200
+++ new/mod_wsgi-4.9.4/src/server/wsgi_apache.c 2022-09-12 03:56:13.000000000
+0200
@@ -52,6 +52,19 @@
/* ------------------------------------------------------------------------- */
+#if !AP_MODULE_MAGIC_AT_LEAST(20101106,1)
+
+apr_status_t wsgi_ap_pool_cleanup_set_null(void *data_)
+{
+ void **ptr = (void **)data_;
+ *ptr = NULL;
+ return APR_SUCCESS;
+}
+
+#endif
+
+/* ------------------------------------------------------------------------- */
+
#if (APR_MAJOR_VERSION == 0) && \
(APR_MINOR_VERSION == 9) && \
(APR_PATCH_VERSION < 5)
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/mod_wsgi-4.9.2/src/server/wsgi_apache.h
new/mod_wsgi-4.9.4/src/server/wsgi_apache.h
--- old/mod_wsgi-4.9.2/src/server/wsgi_apache.h 2022-05-31 02:45:32.000000000
+0200
+++ new/mod_wsgi-4.9.4/src/server/wsgi_apache.h 2022-09-12 03:56:13.000000000
+0200
@@ -128,6 +128,11 @@
#define ap_close_listeners wsgi_ap_close_listeners
#endif
+#if !AP_MODULE_MAGIC_AT_LEAST(20101106,1)
+extern apr_status_t wsgi_ap_pool_cleanup_set_null(void *);
+#define ap_pool_cleanup_set_null wsgi_ap_pool_cleanup_set_null
+#endif
+
#if (APR_MAJOR_VERSION == 0) && \
(APR_MINOR_VERSION == 9) && \
(APR_PATCH_VERSION < 5)
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn'
'--exclude=.svnignore' old/mod_wsgi-4.9.2/src/server/wsgi_version.h
new/mod_wsgi-4.9.4/src/server/wsgi_version.h
--- old/mod_wsgi-4.9.2/src/server/wsgi_version.h 2022-05-31
02:45:32.000000000 +0200
+++ new/mod_wsgi-4.9.4/src/server/wsgi_version.h 2022-09-12
03:56:13.000000000 +0200
@@ -25,8 +25,8 @@
#define MOD_WSGI_MAJORVERSION_NUMBER 4
#define MOD_WSGI_MINORVERSION_NUMBER 9
-#define MOD_WSGI_MICROVERSION_NUMBER 2
-#define MOD_WSGI_VERSION_STRING "4.9.2"
+#define MOD_WSGI_MICROVERSION_NUMBER 4
+#define MOD_WSGI_VERSION_STRING "4.9.4"
/* ------------------------------------------------------------------------- */
