- Move some declarations into the correct #ifdef scope.
I couldn't compile/test netware, but the changes look obvious enough.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@982016 13f79535-47bb-0310-9956-ffa450edef68
numbers themselves if they want, by allowing for
worker create/alloc functions to take a slot number id.
Done via _wid() variants of 3 proxy funcs.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@964089 13f79535-47bb-0310-9956-ffa450edef68
Change the balancer workers area to the address of workers instead copying the workers.
Arrange lbmethod accordingly.
Move the creation of conf->forward worker to mod_proxy child_init().
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@771940 13f79535-47bb-0310-9956-ffa450edef68
transformations which currently fail for balancer://foo targets, but
work just fine with other ProxyReverse targets.
The balancer comparison is a bit trickier. Given the context
BalancerMember balancer://alias http://example.com/foo
ProxyPassReverse /bash balancer://alias/bar
translate url http://example.com/foo/bar/that to /bash/that
E.g. there may be several different url-suffixes (1st order) of any
particular BalancerMember set e.g. /app1, /app1 and /appbeta while
there may be additional suffixes associated with the actual
ProxyPassReverse directive. Neither were properly reversed, now
both should be properly handled.
One *critical* assumption;
BalancerMember balancer://alias/foo http://example.com/bar
should be documented as a meaningless construct, since one cannot
have two members, balancer://alias/foo and balancer://alias/bar,
and the balancer member structures discard this path.
Note one more existing error case as an XXX comment due to invalid
uri comparisons.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@771587 13f79535-47bb-0310-9956-ffa450edef68
reset (initialize) and "age" their data, useful when
adding new workers, or when workers come back into
the fold....
Logic and code to come in a bit :)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@769020 13f79535-47bb-0310-9956-ffa450edef68
backend connection bucket allocator and front end connection bucket allocator.
Instead copy the buckets from the backend over to ones that have been created
using the front end bucket allocator. For metabucket this is done by recreating
them, for data buckets this is done by reading them and putting the read data
in a transient bucket.
PR: 45792
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@712375 13f79535-47bb-0310-9956-ffa450edef68
flushed by using the main requests bytes_count field instead of the
subrequest field.
* Do not reset conn->need_flush. This prevents SegFaults from not flushing
buckets in the filter chain.
PR: 45792
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@706921 13f79535-47bb-0310-9956-ffa450edef68
The call to apr_socket_timeout_set before apr_socket_connect already sets the
socket to non-blocking mode because the timeout of the socket is -1 after creation. A further
call to apr_socket_timeout_set (after the connect call does not do this, because the old
and the new timeout are >=0). The further code expects the socket to be in non-blocking
mode, otherwise we have regressions with ssl. This can be notified by running t/ssl/proxy
on 2.2.x which runs much much slower with the patch applied. This does not happen
on trunk because the socket is set back to non blocking by the core output filter
(async write completion).
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@704753 13f79535-47bb-0310-9956-ffa450edef68
pooled connections if the client connection is an initial connection.
This avoids the "proxy: error reading status line from remote server"
error caused by the race condition that the backend server closed the
connection after the connection check on our side and before our data
reached the backend. Yes, this downgrades performance, especially with
HTTP/1.0 clients. Hence it is configurable and off by default.
PR: 37770
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@684351 13f79535-47bb-0310-9956-ffa450edef68
apr-util this causes a lock during shutdown as at the point of time we would
execute apr_reslist_destroy the reslist is already destroyed, because we are
in a cleanup of the same pool where the reslist registered itself as
precleanup.
With apr-util 1.3.x calling apr_reslist_destroy is not really useful and
needed in this case as we are in a cleanup that was registered against the
same pool that is used by the reslist. As it was registered *after* the
reslist was created it just runs *before* the reslist cleanup would run. This
is somewhat pointless here and we could leave the job of destroying the
reslist to the reslist cleanup.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@682369 13f79535-47bb-0310-9956-ffa450edef68
