This mimetypes contains 'xml', but is unfortunately not an xml file.
xml2enc processes these files (in particular, when mod_proxy_html is
used), typically resulting in them being corrupted as it seems to
attempt to perform a ISO-8859-1 to UTF-8 conversion on them.
* modules/filters/mod_xml2enc.c (xml2enc_ffunc): Restrict test for XML
types to matching "+xml".
Yann Ylavic [Tue, 8 Dec 2020 14:06:16 +0000 (14:06 +0000)]
Fix misleading crypt vs hash terminology in ht* and dbmmanage tools.
What the htpasswd, htdbm and dbmmanage tools do is hashing passwords, not
encrypting them, so fix the terminology in manpages, docs, --help, comments
and function names.
Yann Ylavic [Sun, 6 Dec 2020 23:13:38 +0000 (23:13 +0000)]
mod_proxy_http2: stop/wait the workers threads before their pool is killed.
There shouldn't be any worker thread active when pchild is destroyed (thus each
thread's pool), so register workers_pool_cleanup as a pre_cleanup of pchild.
This is to avoid races like the below stacktrace, where slot_run() threads
are still running when clean_child_exit() is called.
Thread 23 (Thread 0x7f4865b79800 (LWP 3740)):
#0 0x00007f4864dec449 in pthread_cond_destroy@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007f4865020117 in run_cleanups (cref=<optimized out>) at memory/unix/apr_pools.c:2629
#2 pool_clear_debug (pool=pool@entry=0x558a5297e4a0, file_line=0x558a5237456b "event.c:757") at memory/unix/apr_pools.c:1830
#3 0x00007f486501ffee in pool_destroy_debug (pool=0x558a5297e4a0, file_line=<optimized out>) at memory/unix/apr_pools.c:1915
#4 0x00007f48650200f0 in pool_clear_debug (pool=pool@entry=0x558a52a41070, file_line=0x558a5237456b "event.c:757") at memory/unix/apr_pools.c:1827
#5 0x00007f486501ffee in pool_destroy_debug (pool=0x558a52a41070, file_line=<optimized out>) at memory/unix/apr_pools.c:1915
#6 0x00007f486502085c in apr_pool_destroy_debug (pool=<optimized out>, file_line=<optimized out>) at memory/unix/apr_pools.c:1957
#7 0x0000558a52326cfc in clean_child_exit (code=0) at event.c:757
#8 0x0000558a52327969 in child_main (child_num_arg=child_num_arg@entry=1, child_bucket=child_bucket@entry=0) at event.c:2926
#9 0x0000558a52327ce5 in make_child (s=0x558a52c9f840, slot=slot@entry=1, bucket=0) at event.c:2992
#10 0x0000558a52327d4c in startup_children (number_to_start=2, number_to_start@entry=3) at event.c:3015
#11 0x0000558a523289ac in event_run (_pconf=<optimized out>, plog=0x558a5273ce00, s=0x558a52c9f840) at event.c:3374
#12 0x0000558a5233e91e in ap_run_mpm (pconf=0x558a5270cbe0, plog=0x558a5273ce00, s=0x558a52c9f840) at mpm_common.c:100
#13 0x0000558a5231b763 in main (argc=<optimized out>, argv=<optimized out>) at main.c:844
Thread 2 (Thread 0x7f4840b70700 (LWP 3836)):
#0 0x00007f4864dec9f3 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007f486501f65d in apr_thread_cond_wait (cond=<optimized out>, mutex=<optimized out>) at locks/unix/thread_cond.c:68
#2 0x00007f484e14ae4a in get_next (slot=0x558a528d5fe0) at h2_workers.c:209
#3 slot_run (thread=0x558a52828b30, wctx=0x558a528d5fe0) at h2_workers.c:228
#4 0x00007f4864de66db in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#5 0x00007f4864b0f88f in clone () from /lib/x86_64-linux-gnu/libc.so.6
Thread 1 (Thread 0x7f4841b72700 (LWP 3834)):
#0 0x00007f4864a2ce97 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f4864a2e801 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007f4865020865 in apr_pool_destroy_debug (pool=<optimized out>, file_line=<optimized out>) at memory/unix/apr_pools.c:1955
#3 0x00007f486502b536 in apr_thread_exit (thd=thd@entry=0x558a52ba8980, retval=retval@entry=0) at threadproc/unix/thread.c:206
#4 0x00007f484e14aec6 in slot_run (thread=0x558a52ba8980, wctx=0x558a528d6060) at h2_workers.c:248
#5 0x00007f4864de66db in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#6 0x00007f4864b0f88f in clone () from /lib/x86_64-linux-gnu/libc.so.6
Yann Ylavic [Thu, 3 Dec 2020 14:06:17 +0000 (14:06 +0000)]
mod_proxy: provide prefetching and spooling mechanisms to all proxy modules.
Export ap_proxy_prefetch_input(), ap_proxy_spool_input() and
ap_proxy_read_input() from mod_proxy_http to mod_proxy.h/proxy_util.c so
that they are usable by all proxy modules.
mod_proxy_fcgi will use them in a following commit.
Yann Ylavic [Fri, 27 Nov 2020 17:31:09 +0000 (17:31 +0000)]
ap_pbase64decode(): save double NUL byte allocation and assignment.
apr_base64_decode_len() already accounts for the NUL byte, and
apr_base64_decode() already NUL terminates the string, no need
to do it in ap_pbase64decode().
Yann Ylavic [Mon, 23 Nov 2020 11:14:56 +0000 (11:14 +0000)]
mod_auth_digest: fix crash on ONE_PROCESS (debug) mode shutdown.
There need to be separate global variables for rmm and mutex(es) in the parent
and child processes, otherwise in ONE_PROCCESS (were clean_child_exit() and
ap_terminate() execute in the same process) the variables get overwritten in
child_init and freed twice when pchild and then pconf are destroyed.
Yann Ylavic [Mon, 23 Nov 2020 11:03:45 +0000 (11:03 +0000)]
mod_proxy: pconf vs pchild consistency, and correctness in ONE_PROCESS mode.
Consistently use pconf for ap_proxy_define_{worker,balancer}() and pchild for
ap_proxu_initialize_{worker,balancer}() in mod_proxy [child_]init code.
pchild is needed in _initialize() for mutexes/shms' child_init and cleanup,
and to avoid a crash on shutdown (i.e. ap_terminate) in ONE_PROCESS mode,
where worker->cp->pool is destroyed twice, let's register conn_pool_cleanup()
as a pre_cleanup of pchild.
Yann Ylavic [Sun, 22 Nov 2020 22:31:31 +0000 (22:31 +0000)]
core: fix c->client_ip for unix socket connections.
Catch apr_socket_addr_get() error in core_create_conn() to avoid uninitialized
conn_rec->client_ip. This can happen for mod_proxy connections using unix
sockets, which are not handled by apr_socket_addr_get() until APR's r1883728
(trunk only for now).
Yann Ylavic [Fri, 20 Nov 2020 21:20:33 +0000 (21:20 +0000)]
mod_proxy_http2: stop/wait the workers threads before their pool is killed.
There shouldn't be any worker thread active when pchild is destroyed (thus each
thread's pool), so register workers_pool_cleanup as a pre_cleanup of pchild.
This is to avoid races like the below stacktrace, where slot_run() threads
are still running when clean_child_exit() is called.
Thread 23 (Thread 0x7f4865b79800 (LWP 3740)):
#0 0x00007f4864dec449 in pthread_cond_destroy@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007f4865020117 in run_cleanups (cref=<optimized out>) at memory/unix/apr_pools.c:2629
#2 pool_clear_debug (pool=pool@entry=0x558a5297e4a0, file_line=0x558a5237456b "event.c:757") at memory/unix/apr_pools.c:1830
#3 0x00007f486501ffee in pool_destroy_debug (pool=0x558a5297e4a0, file_line=<optimized out>) at memory/unix/apr_pools.c:1915
#4 0x00007f48650200f0 in pool_clear_debug (pool=pool@entry=0x558a52a41070, file_line=0x558a5237456b "event.c:757") at memory/unix/apr_pools.c:1827
#5 0x00007f486501ffee in pool_destroy_debug (pool=0x558a52a41070, file_line=<optimized out>) at memory/unix/apr_pools.c:1915
#6 0x00007f486502085c in apr_pool_destroy_debug (pool=<optimized out>, file_line=<optimized out>) at memory/unix/apr_pools.c:1957
#7 0x0000558a52326cfc in clean_child_exit (code=0) at event.c:757
#8 0x0000558a52327969 in child_main (child_num_arg=child_num_arg@entry=1, child_bucket=child_bucket@entry=0) at event.c:2926
#9 0x0000558a52327ce5 in make_child (s=0x558a52c9f840, slot=slot@entry=1, bucket=0) at event.c:2992
#10 0x0000558a52327d4c in startup_children (number_to_start=2, number_to_start@entry=3) at event.c:3015
#11 0x0000558a523289ac in event_run (_pconf=<optimized out>, plog=0x558a5273ce00, s=0x558a52c9f840) at event.c:3374
#12 0x0000558a5233e91e in ap_run_mpm (pconf=0x558a5270cbe0, plog=0x558a5273ce00, s=0x558a52c9f840) at mpm_common.c:100
#13 0x0000558a5231b763 in main (argc=<optimized out>, argv=<optimized out>) at main.c:844
Thread 2 (Thread 0x7f4840b70700 (LWP 3836)):
#0 0x00007f4864dec9f3 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0
#1 0x00007f486501f65d in apr_thread_cond_wait (cond=<optimized out>, mutex=<optimized out>) at locks/unix/thread_cond.c:68
#2 0x00007f484e14ae4a in get_next (slot=0x558a528d5fe0) at h2_workers.c:209
#3 slot_run (thread=0x558a52828b30, wctx=0x558a528d5fe0) at h2_workers.c:228
#4 0x00007f4864de66db in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#5 0x00007f4864b0f88f in clone () from /lib/x86_64-linux-gnu/libc.so.6
Thread 1 (Thread 0x7f4841b72700 (LWP 3834)):
#0 0x00007f4864a2ce97 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007f4864a2e801 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007f4865020865 in apr_pool_destroy_debug (pool=<optimized out>, file_line=<optimized out>) at memory/unix/apr_pools.c:1955
#3 0x00007f486502b536 in apr_thread_exit (thd=thd@entry=0x558a52ba8980, retval=retval@entry=0) at threadproc/unix/thread.c:206
#4 0x00007f484e14aec6 in slot_run (thread=0x558a52ba8980, wctx=0x558a528d6060) at h2_workers.c:248
#5 0x00007f4864de66db in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#6 0x00007f4864b0f88f in clone () from /lib/x86_64-linux-gnu/libc.so.6
While at it, rename server_pool as pchild in h2_workers_create(), to make it
clear which pool it is.
Yann Ylavic [Fri, 20 Nov 2020 16:31:21 +0000 (16:31 +0000)]
mod_ssl_ct: join the threads before their parent pools are destroyed.
This can happen on stop/restart for the daeomon thread, or on clean_child_exit()
for the service thread.
When an apr_thread_create()d thread exits it destroys its pool (in any case),
either explicitely when apr_thread_exit() is called, or implicitely after the
function returns (only in APR 2.0 for now).
So we should make sure that mod_ssl_ct's daemon and service threads exit before
pconf and pchild (the parent pools, respectively) destroy their children pools,
otherwise the threads' pool will be destroyed twice and cause a crash.
Using a pre_cleanup to wait for the threads avoids this.
Yann Ylavic [Thu, 19 Nov 2020 12:12:04 +0000 (12:12 +0000)]
Make HTTP_IN filter send 100 continue in blocking mode only.
When mod_proxy_http prefetches input data it calls the HTTP_IN filter
in nonblocking mode, but since it does not want 100 continue to be sent
for every case (e.g. 100-continue forwarding), it hacks r->expecting_100
(save in req->expecting_100, reset, eventually restore..) all over the
place.
Let's avoid this by making the HTTP_IN filter send 100 continue only
when called in blocking mode (once still), instead of the first time
it's called.
* modules/http/http_filters.c (struct http_filter_ctx): Add the seen_data
bit and rename eos_sent to at_eos (HTTP_IN does not send any EOS).
* modules/http/http_filters.c (ap_http_filter): Move 100 continue
handling outside the initialization/once block, and do it in blocking
mode only. Track in ctx->seen_data whether some data were already
received, and if so don't send 100 continue per RFC 7231 5.1.1.
* modules/proxy/mod_proxy_http.c: Remove req->expecting_100 (and its
danse with r->expecting_100) now that reading from the input filters
does the right thing.
Yann Ylavic [Wed, 4 Nov 2020 00:32:50 +0000 (00:32 +0000)]
mpm_event: don't reset connections after lingering close timeout
While httpd is supposed to do lingering close for incoming data, it has no
control anyway over outgoing/pending data once they are handled by the
system.
So don't reset the connection after lingering close times out, otherwise the
system won't do its own lingering close to flush un-acked data.
The connection reset was introduced by r1802875 and backported to 2.4.28.
Yann Ylavic [Tue, 3 Nov 2020 23:58:35 +0000 (23:58 +0000)]
mpm_event: don't kill keepalive connections on connections_above_limit().
Before r1819855 (backported to 2.4.30), mpm_event killed keepalive connections
only when workers were exhausted, while this commit set workers_were_busy for
connections_above_limit().
Restore prior to r1819855 behaviour, and since ap_queue_info_num_idlers() is
now part of connections_above_limit(), let's update workers_were_busy there
only when necessary.
Joe Orton [Fri, 30 Oct 2020 10:28:30 +0000 (10:28 +0000)]
Document that KeepAliveTimeout still applies regardless of
how RequestReadTimeout is used (had some user confusion by this
since the behaviour changed within 2.4.x, e.g. PR 56729).
Joe Orton [Thu, 15 Oct 2020 16:04:12 +0000 (16:04 +0000)]
Disable mod_http2 and mod_ssl_ct for prefork builds, since the former
shouldn't be used under prefork and the latter isn't tested at all.
Possibly related to infrequent prefork child segfaults under pool-debug.
e.g. https://travis-ci.org/github/apache/httpd/jobs/736044109
is a multi-threaded prefork child dying with both mod_h2 and mod_ssl_ct
threads active.
projects / thirdparty / apache / httpd.git / log
