Force mod_proxy_fcgi to read the whole FCGI response
even when the content has not been modified (HTTP 304).
The problem is described in PR 59838. This patch should
avoid bogus reads causing the following issues with
HTTP 304 responses:
- AH01068: Got bogus version X, expected 1
- AH01069: Got bogus rid X, expected 1
- AH01075: Error dispatching request to :
- HTTP 503 logged instead of 304 (even if the external
client gets correctly a 304)
As discussed on IRC the HTTP_PRECONDITION_FAILED use case
should be handled like the HTTP_NOT_MODIFIED one but it will
be done in a separate commit.
Jacob Champion [Tue, 12 Jul 2016 19:13:36 +0000 (19:13 +0000)]
CMake: use generator expressions to find output files
Multi-configuration generators, like Visual Studio, use a different
output directory (Debug, Release, etc.) for each configuration. To find
the output files reliably, switch to using generator expressions instead
of hardcoding the file paths for PDBs, export files, etc.
Jacob Champion [Tue, 12 Jul 2016 19:13:34 +0000 (19:13 +0000)]
CMake: use CMAKE_REQUIRED_INCLUDES to find APR macros
When using CMake with Visual Studio on Windows, invoking the
CHECK_SYMBOL_EXISTS macro with the full paths to the include files seems
to always result in failure.
Instead, use the documented CMAKE_REQUIRED_INCLUDES variable to set the
include directory, and pass only the headers' base names to
CHECK_SYMBOL_EXISTS.
Eric Covener [Fri, 8 Jul 2016 21:49:47 +0000 (21:49 +0000)]
PR59815: rewrite per-directory + fcgi broken in 2.4.23
remove the query string from r->filename before calculating environment
(SCRIPT_FILENAME) in mod_proxy_fcgi. Before PR59618, php-fpm would
see proxy:fcgi:// and do some of this same stripping.
Improve the FCGI/CGI Last-Modified header value handling.
Patch from Yann after a discussion on the dev@ mailing list.
ap_scan_script_header_err_core_ex is now using apr_date_parse_rfc
in order to recognize non-GMT datestr following RFC822/1123
and transforming them to GMT rather than replacing the value
with GMT now (that could add httpd's processing time to the
original value). Logging has also been improved from my initial
solution.
Luca Toscano [Thu, 30 Jun 2016 07:00:31 +0000 (07:00 +0000)]
Log CGI/FCGI Last-Modified header value changes.
The Last-Modified header coming from a backend FCGI/CGI script is inspected
by util_script.c to enforce RFC2616 (https://tools.ietf.org/html/rfc2616#section-14.29).
The Last-Modified header also needs to be compliant with RFC882/1123 as stated in
https://tools.ietf.org/html/rfc2616#section-3.3.1, and one important assumption that
httpd makes (correctly, as the RFC suggests) is to assume the GMT timezone. If the datestr
returned by the FCGI/CGI script is set with a different timezone, then the value might be considered
"in the future" and replaced with GMT now() as calculated by httpd. Adding a trace log might
help sysadmins while debugging these kind of issues. This is a follow up of r1748379.
Small change to r952007, ensure we don't wipe out the $enable_foomod value
when that value is 'shared'. The 'yes', 'shared', 'static' and 'no' values
are all valid.
Yann Ylavic [Tue, 28 Jun 2016 13:48:44 +0000 (13:48 +0000)]
mod_proxy: follow up to r1750392 and r1750474.
Restore PROXY_WORKER_IS_USABLE() check in ap_proxy_connect_backend(), we must
obviously (un)put backend in error state based on the result of the actual
connect(), and don't change it in ap_proxy_check_backend()...
APR_SUCCESS return by ap_proxy_check_backend(), i.e. a usable worker and an
established connection, is enough for modules to continue w/o calling
ap_proxy_connect_backend(), still.
Yann Ylavic [Tue, 28 Jun 2016 11:19:36 +0000 (11:19 +0000)]
mod_proxy: follow up to r1750392.
Avoid double checking the connection in ap_proxy_connect_backend() when
ap_proxy_check_backend() says it is up and good to go.
This can be done by moving the PROXY_WORKER_IS_USABLE() check in
ap_proxy_check_backend(), since it is called by ap_proxy_connect_backend(),
and not calling the latter if the former succeeded (for the modules using it).
Yann Ylavic [Mon, 27 Jun 2016 21:49:15 +0000 (21:49 +0000)]
mod_proxy: we don't need ap_proxy_ssl_connection_cleanup() anymore with
ap_proxy_check_backend() used at connection reuse time, so remove its last call and deprecate it.
Yann Ylavic [Mon, 27 Jun 2016 21:45:45 +0000 (21:45 +0000)]
mod_proxy_http2: don't use ap_proxy_ssl_connection_cleanup(), there may be
data available on the backend connection before we reuse it (e.g. PING or SETTINGS change).
Yann Ylavic [Mon, 27 Jun 2016 17:26:12 +0000 (17:26 +0000)]
mod_proxy_{http,ajp,fcgi}}: don't reuse backend connections with data available
before the request is sent. PR 57832.
ap_proxy_check_backend() can be used before ap_proxy_connect_backend() to try
to read available data (including from the filters), and is called by
ap_proxy_connect_backend() to check the socket state only (as before, still
relevant after ap_proxy_check_backend() due to filter data which may not have
triggered a real socket operation).
Replace the proxy_mods_enable logic, with its hazardous 'yes' value that
aborts the build on missing dependencies, with a local override of the
module_selection as 'most', and module_default of the same shared|static
model that was requested through --enable-proxy.
[For trunk, we need to reevaluate the 'most' condition of some of the more
esoteric modules, and simply drop the module_default override; where a user
wants to enable -only- mod_proxy, plus one proxy mechanism, the legacy 2.4.x
behavior retained by this patch is nuts. For one example,
--enable-modules=few --enable-proxy-yes --enable-proxy_http
is a completely specific and legitimate syntax --- adding 10 other proxy
providers in response to this syntax is absurd.]
Cause missing mod_watchdog to 'unset' the --enable-proxy default, rather than
disable the module. This forces the module logic to emit a warning of the
missing dependency; changes the output from
checking whether to enable mod_proxy_hcheck... no
to
configure: WARNING: "mod_watchdog is disabled but required for mod_proxy_hcheck"
checking whether to enable mod_proxy_hcheck... no (disabled)
This has been tested using a slighly modified example taken from:
https://blogs.oracle.com/basant/entry/using_mod_sed_to_filter
(OutputSed "s/.\*//" has been changed in OutputSed "s/.*//")
OutputSed "/Sunday/ {"
OutputSed "h"
OutputSed "s/.*//"
OutputSed "N"
OutputSed "s/\^.//"
OutputSed "/Monday/ {"
OutputSed "x"
OutputSed "s/Sunday/Monday/"
OutputSed "x"
OutputSed "s/Monday/Tuesday/"
OutputSed "H"
OutputSed "g"
OutputSed "}"
OutputSed "}"
Luca Toscano [Sat, 18 Jun 2016 10:13:42 +0000 (10:13 +0000)]
Follow up about DNS Resolution cache in mod-proxy after
a users@ email thread ("mod_proxy and DNS resolving").
Review from devs would be really appreciated, I'd like to
backport this info asap to 2.4.x.
Luca Toscano [Tue, 14 Jun 2016 10:35:23 +0000 (10:35 +0000)]
Drop an invalid Last-Modified header value returned by a FCGI/CGI
script instead tranforming it to Unix Epoch.
This bug was mentioned in the users@ mailing list and outlined in
the following centos bug: https://bugs.centos.org/view.php?id=10940
To reproduce the issue it is sufficient to connect mod-fastcgi
to a PHP script that returns a HTTP response with
the header "Last-Modified: foo". The header will be modified by
script_util.c to "Last-Modified: Thu, 01 Jan 1970 00:00:00 GMT".
Dropping an invalid header in this case seems to be the most
consistent and correct option in my opinion, plus it shouldn't
break existing configurations. Returning Unix Epoch might be
dangerous and should be avoided, but please let me know your opinions.
Moreover this is my first commit outside the documentation court,
I hope to have got the procedure right.
This fix has been tested also with the 2.4.x branch.
projects / apache / log