When a rewrite to proxy is configured in the server config, a check is made to make sure mod_proxy is active. But the same is not done if a rewrite to proxy is configured in an .htaccess file.
Basically this patch is the block of code from hook_uri2file that does the proxy check, copied to hook_fixup.
Patch provided by Michael Streeter [mstreeter1 gmail.com], slightly modified to use a new APLOGNO
PR 56264
- Add some links.
- Remove the space in "character set" in the syntax of ProxyFtpDirCharset to avoid confusion (it is 1 parameter only)
- Use the correct syntax for the "default" values, so that they are parsed and correctly displayed in 'quickreference'
- Remove extra [] when directive's parameter are required
- correct the default password: apache-proxy@ instead of apache_proxy@.
This was silently changed in r88745, 17 years ago!
'ap_unescape_urlencoded()' suggests that NULL can be passed to 'unescape_url()'.
So avoid a potential 'strchr(NULL, ...)' which is an undefined behavior.
Yann Ylavic [Fri, 10 Aug 2018 16:15:50 +0000 (16:15 +0000)]
core: ap_filter_output_pending() to flush outer most filters first.
Since previous output filters may use ap_filter_should_yield() to determine
whether they should send more data (e.g. ap_request_core_filter), we need
to flush pending data from the core output filter first, and so on up the
chain.
Otherwise we may enter an infinite loop where ap_request_core_filter() does
nothing on ap_filter_output_pending() called from MPM event.
Rainer Jung [Tue, 7 Aug 2018 10:25:31 +0000 (10:25 +0000)]
mod_status: Complete the data shown for async
MPMs in "auto" mode. Added number of processes,
number of stopping processes and number
of busy and idle workers.
Rainer Jung [Tue, 7 Aug 2018 10:17:33 +0000 (10:17 +0000)]
mod_proxy: Improve the balancer member data shown
in mod_status when "ProxyStatus" is "On":
add "busy" count and show byte counts in auto
mode always in units of kilobytes.
Yann Ylavic [Fri, 3 Aug 2018 09:53:42 +0000 (09:53 +0000)]
event, worker: initialize the objects used by signal_threads() first.
Follow up to r1835845.
If a signal is received early when the MPM children start, signal_threads() may
be called concurrently with start_streads() thus before the latter (or its
underlying threads like the listener_thread) had a chance to create and init
the queues, mutexes, pollset and sockets array used by the former.
So move those initializations to a new setup_threads_runtime() function called
before start_threads(), where the pruntime pool is also created.
If ProxyPassReverse is used for reverse mapping of relative redirects, subsequent ProxyPassReverse statements, whether they are relative or absolute, may fail.
Jim Jagielski [Wed, 1 Aug 2018 11:27:28 +0000 (11:27 +0000)]
Fix PR54848 in a 2.4.x backportable format. Ideally deprecating the use
of ->client in whatever version of 2.4 this is added into would be
more logical.
mod_ratelimit: Don't interfere with "chunked" encoding.
By the time ap_http_header_filter() sends the header brigade and adds the
"CHUNK" filter, we need to garantee that the header went through all the
filters' stack, and more specifically above ap_http_chunk_filter() which
assumes that all it receives is content data.
Since rate_limit_filter() may retain the header brigade, make it run after
ap_http_chunk_filter(), just before AP_FTYPE_CONNECTION filters.
Also, ap_http_header_filter() shouldn't eat the EOS for HEAD/no-body responses.
For instance mod_ratelimit depends on it since r1835168, but any next request
filter may as well to flush and/or bail out approprietely.
This fixes the regression introduced in 2.4.34 (r1835168).
PR 62568.
mod_proxy_http: follow up to r1836588/r1836648: handle unread 100-continue.
When the backend responds with a non-interim response to a 100-continue,
mod_proxy_http won't read the client's body, so make sure "Connection: close"
ends up being added to the response if nobody reads that body later.
The right thing to do at mod_proxy level, rather then forcing AP_CONN_CLOSE,
is to restore r->expecting_100 so that further processing (like error_override
or trying on the next balancer member) can still work.
Eric Covener [Thu, 26 Jul 2018 00:51:31 +0000 (00:51 +0000)]
expand on ProxyPassReverse args
split up the two arguments into their own paragraphs
try to reinforce that the 2nd arg has to match the response
hedaer, and what the first one is used for.
mod_proxy_http: follow up to r1836588: avoid 100-continue responses from core.
When mod_proxy_http handles end-to-end "100 continue", it can't let
ap_http_filter() send its own interim response whenever the body is read.
So save/restore r->expecting_100 before/after handling the request, and use
req->expecting_100 internally (including to restore r->expecting appropriately).
While at it, add comments and debug logs about 100 continue handling, and
fill in missing APLOGNO()s from r1836588.
* ap_proxy_balancer_get_best_worker cannot be exported and used as an optional
function at the same time. So rename ap_proxy_balancer_get_best_worker to
proxy_balancer_get_best_worker and make it static which is then used as an
optional function and recreate ap_proxy_balancer_get_best_worker as an
exported thin wrapper of proxy_balancer_get_best_worker.
Handle end-to-end 100-continue, according to RFC 7231, such that the client
request body is not read/forwarded (according to its "Expect:" header) until
the backend wants to receive it (with interim 100 continue response), or never
forwarded if the backend provides a (non-interim) response and doesn't need
the client body at all.
This is achieved by filling the header_brigade in ap_proxy_http_prefetch()
and letting ap_proxy_http_request() determine whether it should forward that
brigade only (with the "Expect: 100-continue" specified by the client or added
according to "ping=" configuration), or forward the whole body for the usual
case (as before).
When 100-continue expectation is in place, the body is actually forwarded by
ap_proxy_http_process_response() when/if a "100 continue" response is sent by
the backend, otherwise the body is discarded; a future enhancement could make
so that in a balancer configuration, the body could be forwarded to another
balancer member depending on the status/error from the backend.
So stream_reqbody_cl() and stream_reqbody_chunked() functions are adapted to be
called by either ap_proxy_http_request() or ap_proxy_http_process_response(),
while spool_reqbody_cl() still spools the body in ap_proxy_http_prefetch() thus
before the backend is connected/reused to avoid inactivity on the connection
for the prefetch time (the prefetched body is also forwarded according to the
100-continue expectation, though).
Also, since the brigades and other runtime objects now need to be shared by the
ap_proxy_http_*() functions chain, a proxy_http_req_t struct/context is created
from the start and passed to them as (the single) argument. This is also a good
candidate for a future async baton, if we wanted to let the MPM event wait for
connection data for us at any stage and be called back ;)
Finally, ap_send_interim_response() is modified to correcly handle 100 continue
responses once, and take care of clearing r->expecting_100 only for them.
* mod_proxy: Remove load order and link dependency between mod_lbmethod_*
modules and mod_proxy by providing mod_proxy's ap_proxy_balancer_get_best_worker
as an optional function.
They were superseded by ap_filter_should_yield() and ap_run_in/output_pending()
in r1706669 and had poor semantics since then (we can't maintain pending
semantics both by filter and for the whole connection).
Register ap_filter_input_pending() as the default input_pending hook (which
seems to have been forgotten in the first place).
On the MPM event side, we don't need to flush pending output data when the
connection has just been processed, ap_filter_should_yield() is lightweight and
enough to determine whether we should really enter write completion state or go
straight to reading. ap_run_output_pending() is used only when write completion
is in place and needs to be completed before more processing.
mod_proxy_hcheck: take balancer's SSLProxy* directives into account.
mod_proxy_hcheck was missing the merge of SSLProxy* directives defined by
balancer with the ones of the VirtualHost.
Since ap_proxy_connection_create_ex() needs a merged r->per_dir_config to apply
the correct SSL configuration, let's split create_request_rec() in two:
- create_request_rec() to only initialize the non-connection fields and merge
balancer->section_config into r->per_dir_config,
- set_request_connection() to associate the connection with the request once
it's been created from the merged configuration of the minimal request.
core: integrate data_in_{in,out}put_filter to ap_filter_{in,out}put_pending().
Straightforward for ap_filter_input_pending() since c->data_in_input_filter is
always checked wherever ap_run_input_pending(c) is.
For ap_filter_output_pending(), this allows to set c->data_in_output_filter in
ap_process_request_after_handler() and avoid an useless flush from mpm_event.
The core output filter used to determine first if it needed to block before
trying to send its data (including set aside ones), and if so it did call
send_brigade_blocking().
This can be avoided by making send_brigade_nonblocking() send as much data as
possible (nonblocking), and only if data remain check whether they should be
flushed (blocking), according to the same ap_filter_reinstate_brigade()
heuristics but afterward.
This allows both to simplify the code (axe send_brigade_blocking and some
duplicated logic) and optimize sends since send_brigade_nonblocking() is now
given all the buckets so it can make use of scatter/gather (iovec) or NOPUSH
option with the whole picture.
When sendfile is available and/or with fine tuning of FlushMaxThreshold (and
ReadBufferSize) from r1836032, one can now take advantage of modern network
speeds and bandwidth.
This commit also adds some APLOG_TRACE6 messages for outputed bytes (including
at mod_ssl level since splitting happens there when it's active).
core: Add ReadBufferSize, FlushMaxThreshold and FlushMaxPipelined directives.
ReadBufferSize allows to configure the size of read buffers, for now it's
mainly used for file buckets reads (apr_bucket_file_set_buf_size), but it could
be used to replace AP_IOBUFSIZE in multiple places.
FlushMaxThreshold and FlushMaxPipelined allow to configure the hardcoded
THRESHOLD_MAX_BUFFER and MAX_REQUESTS_IN_PIPELINE from "util_filter.c".
The former sets the maximum size above which pending data are forcibly flushed
to the network (blocking eventually), and the latter sets the number of
pipelined/pending responses above which they are flushed regardless of whether
a pipelined request is immediately available (zero disables pipelining).
Larger ReadBufferSize and FlushMaxThreshold can trade memory consumption for
performances with the capacity of today's networks.
Since it's internal util_filter use, we shouldn't expose it in conn_rec and
can replace it with a pooled brigade provided by ap_reuse_brigade_from_pool().
util_filter: follow up to r1835640: pending_filter_cleanup() precedence.
Register pending_filter_cleanup() as a normal cleanup (not pre_cleanup) so
that the pending filters are still there on pool cleanup, and f->bb is set
to NULL where needed.
Then is_pending_filter() check is moved where relevant.
Always favor APR_POLLSET_WAKEABLE over method/implementation.
Probably more about correctness than a real issue since systems are
unlikely to implement more than one/their method...
This also makes use of pruntime for event_pollset (an oversight from r1835845).
projects / apache / log