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
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
This used to check for the backend connection readability only (instead of
the full ping/100-continue round-trip), but the case is already handled by
ap_proxy_connect_backend() which is always called.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1729507 13f79535-47bb-0310-9956-ffa450edef68
Handle the proxy-error-override note also in mod_proxy_ajp.
The note is not needed in mod_proxy_fcgi (which also handles
ProxyErrorOverride) since it calls ap_die() by itself, and always
returns OK to proxy_handler().
Add a comment about the note where used.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1682907 13f79535-47bb-0310-9956-ffa450edef68
Since any read/write error is caught by this flag, it really means "dialog with
client <ip:port> failed" (as per the associated log message), whereas write to
client (output) errors need not be handled differently than any error occuring
after some bytes have already been sent to the client, which is the purpose of
the data_sent flag.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1674056 13f79535-47bb-0310-9956-ffa450edef68
More uses of ap_map_http_request_error() and AP_FILTER_ERROR so that we never
return an HTTP error status from a handler if some filter generated a response
already.
That is, from a handler, either ap_get_brigade() (an input filter) returned
AP_FILTER_ERROR and we must forward it to ap_die(), or ap_pass_brigade() (an
output filter) failed with any status and we must return AP_FILTER_ERROR in
any case for ap_die() to determine whether a response is needed or not.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1665625 13f79535-47bb-0310-9956-ffa450edef68
input filter already did it while reading client's payload.
When an input filter returns AP_FILTER_ERROR, it has already called ap_die()
or at least already responded to the client.
Here we don't want to lose AP_FILTER_ERROR when returning from proxy handlers,
so we use ap_map_http_request_error() to forward any AP_FILTER_ERROR to
ap_die() which knows whether a response needs to be completed or not.
Before this commit, returning an HTTP error code in this case caused a double
response to be generated.
Depends on r1657881 to preserve r->status (for logging) when nothing is to be
done by ap_die() when handling AP_FILTER_ERROR.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1657897 13f79535-47bb-0310-9956-ffa450edef68
clength in request_rec is for response sizes,
not request body size. It is initialized to 0,
so the "if" branch was never taken.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1649043 13f79535-47bb-0310-9956-ffa450edef68
if we added the default port or not during the canonizing
phase... Baseline the http method (don't add unless the
port provided isn't the default).
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1542562 13f79535-47bb-0310-9956-ffa450edef68
we pinged it successfully before don't assume the whole backend has failed.
Assume that only the request has failed and return a gateway timeout then.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1398307 13f79535-47bb-0310-9956-ffa450edef68
The field "closed" was changed from an int to a bit
field of size one in 2.4.x.
For historical reasons a close instruction was coded
as an increment on the field, which in 2.4.x flips
the field each time. There were mutliple code paths
that would flip it several times for a single error,
so effectively the connection was no longer closed
in these cases.
Especially in the case of an aborted client connection
this lead to a non consumed back end buffer and thus to
response mixup between users.
PR 53727
CVE-2012-3052
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1373955 13f79535-47bb-0310-9956-ffa450edef68
Remove the comment about binding upstream and downstream connections. It
seems to be obsolete since r104604, r104605, r105108.
Also avoid allocating memory if we are not handling the connection.
PR: 52275
Submitted by: Naohiro Ooiwa <naohiro ooiwa miraclelinux com>, Stefan Fritsch
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1334343 13f79535-47bb-0310-9956-ffa450edef68
* remove "proxy:", "FCGI", etc. prefixes and pid which are now
included in the error log format
* propagate frontend request's logconfig to backend request
* use ap_log_rerror where possible
* remove obsolete APLOG_NOERRNO
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1203859 13f79535-47bb-0310-9956-ffa450edef68
have not been sent by the AJP server so far. Even an empty brigade
will trigger the headers filter to create the (in this case incomplete)
HTTP headers of the response.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1153531 13f79535-47bb-0310-9956-ffa450edef68
