backend connection, happening with LogLevel trace2 or higher configured,
or at any log level with compilers not detected as C99 compliant (e.g.
MSVC on Windows).
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1775775 13f79535-47bb-0310-9956-ffa450edef68
*) mod_proxy: Honor a server scoped ProxyPass exception when ProxyPass is
configured in <Location>, like in 2.2. PR 60458.
[Eric Covener]
reverted in r1781324
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1773397 13f79535-47bb-0310-9956-ffa450edef68
To help out users when debugging ProxyPass and ProxyPassMatch, log all
match attempts (at trace2), as well as matches that are either
successful or explicitly disabled (at trace1).
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1762517 13f79535-47bb-0310-9956-ffa450edef68
This is a follow up of http://svn.apache.org/r1752347;
ap_meet_conditions could return a 412 status that if not
handled causes subsequent bogus reads and wrong messages
logged (like AH01070). After a chat on dev@ the feedback
was to couple HTTP_NOT_MODIFIED with HTTP_PRECONDITION_FAILED,
but any other feedback is welcome.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1759984 13f79535-47bb-0310-9956-ffa450edef68
Export [ap_]check_pipeline() and use it also for ap_proxy_check_connection(),
so that all the necessary checks on the connection are done before reusing it.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1756186 13f79535-47bb-0310-9956-ffa450edef68
Don't try to read past AP_FCGI_END_REQUEST on the backend side, it would be
a response for the next request.
[Reverted by r1755931]
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1755930 13f79535-47bb-0310-9956-ffa450edef68
takes place, the response it to be handled by ErrorDocument is this case.
Also it useless to take care of pre-read data since the body is discarded in
this case.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1754974 13f79535-47bb-0310-9956-ffa450edef68
Background: https://bz.apache.org/bugzilla/show_bug.cgi?id=59838
This commit should be an improvement for http://svn.apache.org/r1752347, in which
I tried to resolve a long standing issue with mod_proxy_fcgi: when a FCGI backend
returns a response that will become a HTTP 304, mod_proxy_fcgi forces a break
in the request processing ending up in reading the remaining bytes (for example
the message-body) and trying to intepret them as a FCGI header. This would cause
a error and a weird behavior:
1) HTTP 304 response flushed to the client correctly.
2) HTTP 503 logged in the access_log plus other bogus errors in the error_log.
I tried to separate the behavior when connection reuse is set or not, to eliminate
unnecessary latency in the latter case (which is the default).
I tested the change with and without connection reuse successfully, but feedback is
really welcome. If nobody will have anything against it I'll then proceed to update
my 2.4.x backport proposal.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1754732 13f79535-47bb-0310-9956-ffa450edef68
This commit should solve the issue indicated in PR 55415.
Httpd loops while serving a error document if:
1) The error document's content is proxied.
2) ProxyErrorOverride is set.
The solution proposed is to limit the use of ap_die only
to the initial request. I tested the change with very basic
scenarios but I am not sure if I got all the use cases,
feedback is really welcome.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1753167 13f79535-47bb-0310-9956-ffa450edef68
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.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1752347 13f79535-47bb-0310-9956-ffa450edef68
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.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1751970 13f79535-47bb-0310-9956-ffa450edef68
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.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1750508 13f79535-47bb-0310-9956-ffa450edef68
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).
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1750474 13f79535-47bb-0310-9956-ffa450edef68
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).
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1750392 13f79535-47bb-0310-9956-ffa450edef68
