flood_farm.c
Hi, flood_farm.c contains these lines for almost 9 years (since Revision 89675): #if 0 /* this gets uncommented after apr_thread_exit() fixes are commited */ apr_thread_exit(thd, APR_SUCCESS); #endif Are those fixes committed now? I mean is the apr_thread_exit to be called now or are those 3 lines simply superfluous? Torsten Förtsch -- Need professional modperl support? Hire me! (http://foertsch.name) Like fantasy? http://kabatinte.net
Re: [RELEASE CANDIDATE] Apache-Test-1.33 RC1
On Saturday, September 11, 2010 08:38:46 Fred Moyer wrote: > http://people.apache.org/~phred/Apache-Test-1.33-rc2.tar.gz +1 opensuse 11.3 self-compiled perl 5.12.1 x86_64, useithreads=undef, usemultiplicity=undef apache Server version: Apache/2.2.16 (Unix) Server built: Sep 9 2010 15:10:55 Server's Module Magic Number: 20051115:24 Server loaded: APR 1.4.2, APR-Util 1.3.9 Compiled using: APR 1.4.2, APR-Util 1.3.9 Architecture: 64-bit Server MPM: Prefork Thanks, Fred. Torsten Förtsch -- Need professional modperl support? Hire me! (http://foertsch.name) Like fantasy? http://kabatinte.net
Re: [RELEASE CANDIDATE] Apache-Test-1.35 RC1
On Thursday, January 20, 2011 17:40:21 Fred Moyer wrote: > One more A-T release is needed before we can roll the mod_perl 2.0.5 rc. > > http://people.apache.org/~phred/Apache-Test-1.35-rc1.tar.gz t/alltest/all.t .. skipped: testing all.t t/alltest2/all.t . skipped: testing more than one all.t t/bad_coding.t ... ok t/cookies.t .. ok t/import.t ... ok t/log_watch.t ok t/more/01testpm.t ok t/more/02testmore.t .. ok t/more/03testpm.t ok t/more/04testmore.t .. ok t/next_available_port.t .. ok t/ping.t . ok t/redirect.t . ok t/request.t .. ok t/sok.t .. ok All tests successful. Files=15, Tests=94, 11 wallclock secs ( 0.10 usr 0.03 sys + 6.88 cusr 0.47 csys = 7.48 CPU) Result: PASS [warning] server localhost.localdomain:8529 shutdown looks good, clean error_log +1 Torsten Förtsch -- Need professional modperl support? Hire me! (http://foertsch.name) Like fantasy? http://kabatinte.net
Re: [RELEASE CANDIDATE] Apache-Test-1.36 RC1
On Tuesday, February 01, 2011 07:54:43 Fred Moyer wrote: > http://people.apache.org/~phred/Apache-Test-1.36-rc1.tar.gz +1 Torsten Förtsch -- Need professional modperl support? Hire me! (http://foertsch.name) Like fantasy? http://kabatinte.net === Special Tests Sequence Failure Finder Report === First iteration used: /opt/perl/bin/perl /home/r2/work/mp2/trunk/tmp/Apache-Test-1.36-rc1/t/TEST t/more/01testpm.t t/alltest2/all.t t/alltest/all.t t/cookies.t t/ping.t t/next_available_port.t t/log_watch.t t/bad_coding.t t/request.t t/more/04testmore.t t/redirect.t t/import.t t/more/02testmore.t t/more/03testpm.t t/sok.t = Summary == Completion : Completed Status : +++ OK +++ Tests run: 150 Iterations (random) made : 10 --- Started at: Wed Feb 2 10:56:16 2011 --- --- Ended at: Wed Feb 2 11:00:26 2011 --- The smoke testing was run on the system with the following parameters: *** "/opt/apache-prefork/sbin/httpd" -V Server version: Apache/2.2.16 (Unix) Server built: Jan 22 2011 18:26:03 Server's Module Magic Number: 20051115:24 Server loaded: APR 1.4.2, APR-Util 1.3.9 Compiled using: APR 1.4.2, APR-Util 1.3.9 Architecture: 64-bit Server MPM: Prefork threaded: no forked: yes (variable process count) Server compiled with -D APACHE_MPM_DIR="server/mpm/prefork" -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D DYNAMIC_MODULE_LIMIT=512 -D HTTPD_ROOT="/opt/apache-prefork" -D SUEXEC_BIN="/opt/apache-prefork/bin/suexec" -D DEFAULT_PIDLOG="/var/opt/apache-prefork/run/httpd.pid" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_LOCKFILE="/var/opt/apache-prefork/run/accept.lock" -D DEFAULT_ERRORLOG="logs/error_log" -D AP_TYPES_CONFIG_FILE="/etc/opt/apache-prefork/mime.types" -D SERVER_CONFIG_FILE="/etc/opt/apache-prefork/httpd.conf" *** /usr/bin/ldd "/opt/apache-prefork/sbin/httpd" linux-vdso.so.1 => (0x7fffd13ff000) libm.so.6 => /lib64/libm.so.6 (0x7f563fd5b000) libaprutil.so.0 => /opt/apr/lib/libaprutil.so.0 (0x7f563fb38000) libdb-4.5.so => /usr/lib64/libdb-4.5.so (0x7f563f801000) libexpat.so.1 => /lib64/libexpat.so.1 (0x7f563f5d7000) libapr.so.0 => /opt/apr/lib/libapr.so.0 (0x7f563f3a8000) libuuid.so.1 => /lib64/libuuid.so.1 (0x7f563f1a3000) librt.so.1 => /lib64/librt.so.1 (0x7f563ef9a000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x7f563ed5f000) libpthread.so.0 => /lib64/libpthread.so.0 (0x7f563eb42000) libdl.so.2 => /lib64/libdl.so.2 (0x7f563e93e000) libc.so.6 => /lib64/libc.so.6 (0x7f563e5de000) /lib64/ld-linux-x86-64.so.2 (0x7f563ffb2000) *** "/opt/perl/bin/perl" -V Summary of my perl5 (revision 5 version 12 subversion 3) configuration: Platform: osname=linux, osvers=2.6.34.7-0.7-desktop, archname=x86_64-linux uname='linux opi.home 2.6.34.7-0.7-desktop #1 smp preempt 2010-12-13 11:13:53 +0100 x86_64 x86_64 x86_64 gnulinux ' config_args='-ds -e -Dprefix=/opt/perl -Dvendorprefix=/opt/perl -Dvendorman1dir=/opt/perl/vendorman/man1 -Dvendorman3dir=/opt/perl/vendorman/man3 -Dvendorbin=/opt/perl/vendorbin -Dvendorscript=/opt/perl/vendorbin -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Duseshrplib=true -Doptimize=-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -pipe -Accflags=-DPERL_USE_SAFE_PUTENV -Dnoextensions=ODBM_File -Uuseithreads -Uusemultiplicity -UDEBUGGING' hint=recommended, useposix=true, d_sigaction=define useithreads=undef, usemultiplicity=undef useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -Wall -pipe -Accflags=-DPERL_USE_SAFE_PUTENV', cppflags='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include' ccversion='', gccv
Bug in mod_log_config
Hi,
mod_log_config contains these lines
static const char *set_buffered_logs_on(cmd_parms *parms, void *dummy, int
flag)
{
buffered_logs = flag;
if (buffered_logs) {
ap_log_set_writer_init(ap_buffered_log_writer_init);
ap_log_set_writer(ap_buffered_log_writer);
}
return NULL;
}
The buffered_logs global variable reflects the BufferedLogs directive.
Now, if my config file contains the 2 lines
BufferedLogs On
BufferedLogs Off
in that order the first directive turns buffered logs on and sets the writer
functions. The 2nd directive turns the buffered_logs flag off but doesn't
reset the writer functions. Hence, if your config contains those lines the
httpd will segfault at startup.
Further, when mod_log_config is compiled as a shared module it is unloaded and
the global variables buffered_logs, log_writer and log_writer_init are reset
during a restart via SIG{HUP,USR1}. But if the module is compiled statically
those global variables keep their values and a similar situation as described
above can appear.
I have found that in 2.2.17. But I have verified it is also present in trunk.
The enclosed patch cures the problem.
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
--- modules/loggers/mod_log_config.c~ 2010-08-24 08:41:38.0 +0200
+++ modules/loggers/mod_log_config.c 2011-03-03 13:31:11.018338617 +0100
@@ -1171,6 +1171,10 @@
ap_log_set_writer_init(ap_buffered_log_writer_init);
ap_log_set_writer(ap_buffered_log_writer);
}
+else {
+ap_log_set_writer_init(ap_default_log_writer_init);
+ap_log_set_writer(ap_default_log_writer);
+}
return NULL;
}
static const command_rec config_log_cmds[] =
@@ -1543,6 +1547,10 @@
log_pfn_register(p, "R", log_handler, 1);
}
+buffered_logs = 0;
+ap_log_set_writer_init(ap_default_log_writer_init);
+ap_log_set_writer(ap_default_log_writer);
+
return OK;
}
Re: Bug in mod_log_config
On Thursday, March 03, 2011 13:44:57 Torsten Förtsch wrote: > I have found that in 2.2.17. But I have verified it is also present in > trunk. Now filed as https://issues.apache.org/bugzilla/show_bug.cgi?id=50861 Torsten Förtsch -- Need professional modperl support? Hire me! (http://foertsch.name) Like fantasy? http://kabatinte.net
Re: Bug in mod_log_config
On Thursday, March 03, 2011 14:55:40 Jim Jagielski wrote: > Thx for the report and the patch... I will verify and apply > to trunk w/ a backport req for 2.2. any progress on that? > On Mar 3, 2011, at 8:45 AM, Torsten Förtsch wrote: > > On Thursday, March 03, 2011 13:44:57 Torsten Förtsch wrote: > >> I have found that in 2.2.17. But I have verified it is also present in > >> trunk. > > > > > > > > Now filed as https://issues.apache.org/bugzilla/show_bug.cgi?id=50861 Torsten Förtsch -- Need professional modperl support? Hire me! (http://foertsch.name) Like fantasy? http://kabatinte.net
Re: Bug in mod_log_config
On Thursday, March 03, 2011 14:55:40 Jim Jagielski wrote: > Thx for the report and the patch... I will verify and apply > to trunk w/ a backport req for 2.2. Just a polite reminder. > On Mar 3, 2011, at 8:45 AM, Torsten Förtsch wrote: > > On Thursday, March 03, 2011 13:44:57 Torsten Förtsch wrote: > >> I have found that in 2.2.17. But I have verified it is also present in > >> trunk. > > > > > > > > Now filed as https://issues.apache.org/bugzilla/show_bug.cgi?id=50861 Torsten Förtsch -- Need professional modperl support? Hire me! (http://foertsch.name) Like fantasy? http://kabatinte.net
Re: Bug in mod_log_config
On Thursday, March 17, 2011 16:05:12 Jim Jagielski wrote: > Added in r1082518. Thanks. Torsten Förtsch -- Need professional modperl support? Hire me! (http://foertsch.name) Like fantasy? http://kabatinte.net
Per module LogLevel parsing
Hi, the new per module LogLevel syntax is documented as LogLevel modulename:level ... where level is a certain value out of a predefined set. The string "modulename:level" is then parsed in core.c/set_loglevel by: level_str = ap_strchr(arg, ':'); This finds the first occurrence of a colon in the string. But shouldn't it rather be the last one? level_str = ap_strrchr(arg, ':'); The point is, if a module is written in Perl its name can very well contain colons. Is it too late to request this change? Should I create a bug report? (It's actually not a bug as such.) Thanks, Torsten Förtsch -- Need professional modperl support? Hire me! (http://foertsch.name) Like fantasy? http://kabatinte.net
ap_read_config in 2.3.11
Hi, I am working on porting modperl to the upcoming httpd 2.4. One problem is the line conf_vector_length = total_modules; in ap_read_config (config.c:2300). Modperl provides a way to write modules in Perl. These modules are loaded by the directive PerlLoadModule which is executed later than line 2300. Such modules are then appended to the module list, get a module structure, can create config directives etc. They also have a module index and allocate their place in config vectors. Now, the line above limits the config vector length to the number of modules known before any one perl module could be loaded. How can this situation be solved? Thanks, Torsten Förtsch -- Need professional modperl support? Hire me! (http://foertsch.name) Like fantasy? http://kabatinte.net
Re: ap_read_config in 2.3.11
On Monday, April 11, 2011 21:14:53 Stefan Fritsch wrote:
> I guess the optimization could be done later, after the config has
> been parsed completely. That would waste some memory in pconf but
> still preserve the optimization during request processing, which is
> more important.
The enclosed patch moves the conf_vector_length adjustment to when
ap_process_config_tree() has done its work. I think that is enough for
mod_perl.
On Tuesday, April 12, 2011 18:24:28 William A. Rowe Jr. wrote:
> Suggestion - an EXEC_ON_READ 'DynamicModulesMax' directive, which would
> let us conf_vector_length = total_modules + dyn_modules_max; after the
> read_config, and finally lock down conf_vector_length = total_modules;
> at the end of post_config. WDYT?
But yes, moving the adjustment to postconfig will solve the problem more
generally. I'll see if I can conceive a patch.
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
Index: server/config.c
===
--- server/config.c (revision 1091323)
+++ server/config.c (working copy)
@@ -1953,6 +1953,12 @@
return NULL;
}
+static apr_status_t reset_conf_vector_length(void *dummy)
+{
+conf_vector_length = max_modules;
+return APR_SUCCESS;
+}
+
AP_DECLARE(int) ap_process_config_tree(server_rec *s,
ap_directive_t *conftree,
apr_pool_t *p,
@@ -1981,6 +1987,20 @@
return HTTP_INTERNAL_SERVER_ERROR;
}
+/*
+ * We have loaded the dynamic modules. From now on we know exactly how
+ * long the config vectors need to be.
+ *
+ * You may be tempted to move the next 3 lines to ap_read_config()
+ * just after ap_process_resource_config() to save a few bytes in pconf
+ * since at that point all the LoadModule directives have been processed.
+ * Don't do that because it breaks stuff like mod_perl that offer a
+ * way to register modules as part of their configuration.
+ */
+conf_vector_length = total_modules;
+apr_pool_cleanup_register(p, NULL, reset_conf_vector_length,
+ apr_pool_cleanup_null);
+
return OK;
}
@@ -2255,12 +2275,6 @@
}
-static apr_status_t reset_conf_vector_length(void *dummy)
-{
-conf_vector_length = max_modules;
-return APR_SUCCESS;
-}
-
AP_DECLARE(server_rec*) ap_read_config(process_rec *process, apr_pool_t *ptemp,
const char *filename,
ap_directive_t **conftree)
@@ -2309,14 +2323,6 @@
return NULL;
}
-/*
- * We have loaded the dynamic modules. From now on we know exactly how
- * long the config vectors need to be.
- */
-conf_vector_length = total_modules;
-apr_pool_cleanup_register(p, NULL, reset_conf_vector_length,
- apr_pool_cleanup_null);
-
error = process_command_config(s, ap_server_post_read_config, conftree,
p, ptemp);
segfault in httpd 2.3.11-beta
Hi,
as an experiment to see if the segfault I am currently debugging were caused
by my modifications I found this. Httpd segfaults if its startup is aborted
because the DYNAMIC_MODULE_LIMIT is hit. The reason is that the module that
caused the abort is first unloaded as dso and then used in ap_remove_module as
ap_top_module. Unfortunately, the memory segment where the module is located
is already wiped from the process' address space at the time.
This happens because both apr_dso_load and mod_so:load_module register a pool
cleanup to undo their effects. These cleanup functions are called in the wrong
order.
I see 2 ways how to prevent that:
1) change in mod_so.c line 305 from
apr_pool_cleanup_register(cmd->pool, modi, unload_module,
apr_pool_cleanup_null);
to
apr_pool_pre_cleanup_register(cmd->pool, modi, unload_module);
This way ap_remove_module will be called before the dso is unloaded.
2) check for possible errors in ap_add_module() before performing any changes:
@@ -541,16 +565,11 @@
m->name, m->version, MODULE_MAGIC_NUMBER_MAJOR);
}
-if (m->next == NULL) {
-m->next = ap_top_module;
-ap_top_module = m;
-}
-
if (m->module_index == -1) {
m->module_index = total_modules++;
dynamic_modules++;
if (dynamic_modules > DYNAMIC_MODULE_LIMIT) {
return apr_psprintf(p, "Module \"%s\" could not be loaded, "
"because the dynamic module limit was "
"reached. Please increase "
@@ -568,6 +587,13 @@
}
}
+if (m->next == NULL) {
+m->next = ap_top_module;
+ap_top_module = m;
+}
+
if (sym_name) {
int len = strlen(sym_name);
int slen = strlen("_module");
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
Re: segfault in httpd 2.3.11-beta
On Thursday, April 14, 2011 19:55:30 Torsten Förtsch wrote:
> Httpd segfaults if its startup is aborted
> because the DYNAMIC_MODULE_LIMIT is hit.
Here is a better cure.
To trigger the bug the attached config.nice can be used. It compiles all
modules as shared and sets DYNAMIC_MODULE_LIMIT=10.
An attempt to start the httpd with the default config will show a message like
"Module "mod_authz_owner.c" could not be loaded, because the dynamic module
limit was reached. Please increase DYNAMIC_MODULE_LIMIT and recompile." and
then segfault.
With the patch ap_add_module() first checks for all possible errors and starts
to change global data structures only if all is well.
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
config.nice
Description: application/shellscript
Index: server/config.c
===
--- server/config.c (revision 1092669)
+++ server/config.c (working copy)
@@ -541,22 +541,17 @@
m->name, m->version, MODULE_MAGIC_NUMBER_MAJOR);
}
-if (m->next == NULL) {
-m->next = ap_top_module;
-ap_top_module = m;
-}
-
if (m->module_index == -1) {
-m->module_index = total_modules++;
-dynamic_modules++;
-
-if (dynamic_modules > DYNAMIC_MODULE_LIMIT) {
+if (dynamic_modules >= DYNAMIC_MODULE_LIMIT) {
return apr_psprintf(p, "Module \"%s\" could not be loaded, "
"because the dynamic module limit was "
"reached. Please increase "
"DYNAMIC_MODULE_LIMIT and recompile.", m->name);
}
+m->module_index = total_modules++;
+dynamic_modules++;
+
}
else if (!sym_name) {
while (sym->modp != NULL) {
@@ -568,6 +563,11 @@
}
}
+if (m->next == NULL) {
+m->next = ap_top_module;
+ap_top_module = m;
+}
+
if (sym_name) {
int len = strlen(sym_name);
int slen = strlen("_module");
Re: segfault in httpd 2.3.11-beta
On Friday, April 15, 2011 14:33:32 Torsten Förtsch wrote: > Here is a better cure. Now also available as bug #51072: https://issues.apache.org/bugzilla/show_bug.cgi?id=51072 Torsten Förtsch -- Need professional modperl support? Hire me! (http://foertsch.name) Like fantasy? http://kabatinte.net
Is this a test framework bug?
Hi,
t/modules/proxy.t of the test framework contains at line 32 the following 2
tests:
$r = GET("/reverse/modules/cgi/nph-102.pl");
ok t_cmp($r->code, 200, "reverse proxy to nph-102");
ok t_cmp($r->content, "this is nph-stdout", "reverse proxy 102 response");
The test fails here and I think the test is wrong. When accessed via socat I
see this output:
echo -e 'GET /reverse/modules/cgi/nph-102.pl HTTP/1.1\r\nHost:
localhost:8538\r\n\r' | socat stdio tcp:localhost.localdomain:8538
HTTP/1.1 102 Please Wait...
Host: nph-102
HTTP/1.1 200 OK
Date: Sun, 17 Apr 2011 15:30:30 GMT
Server: Apache/2.3.12-dev (Unix) mod_ssl/2.3.12-dev OpenSSL/1.0.0 DAV/2
Content-Type: text/plain
Transfer-Encoding: chunked
12
this is nph-stdout
0
I believe this is what is to be expected.
But the test above tests for status 200 only. So, it will succeed if the proxy
module eats up the 102 message. This may be a problem with my libwww-perl. LWP
has recently experienced a major release upgrade. It reports $r->code as 102.
Perhaps older versions report the 2nd response only.
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
httpd-framework: a few forgotten need_module()s
Hi,
t/apache/if_sections.t needs the proxy module, t/modules/filter.t needs
mod_case_filter.
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
Index: t/apache/if_sections.t
===
--- t/apache/if_sections.t (revision 1094143)
+++ t/apache/if_sections.t (working copy)
@@ -12,6 +12,7 @@
plan tests => 11*2,
need need_lwp,
need_module('mod_headers'),
+ need_module('mod_proxy'),
need_min_apache_version('2.3.8');
Index: t/modules/filter.t
===
--- t/modules/filter.t (revision 1094143)
+++ t/modules/filter.t (working copy)
@@ -6,7 +6,7 @@
use Apache::TestUtil qw(t_cmp t_write_file);
use File::Spec;
-plan tests => 1, need need_module('mod_filter');
+plan tests => 1, need need_module('mod_filter'), need_module('mod_case_filter');
my $r = GET_BODY('/modules/cgi/xother.pl');
Re: ap_read_config in 2.3.11
On Tuesday, April 12, 2011 18:24:28 William A. Rowe Jr. wrote:
> Suggestion - an EXEC_ON_READ 'DynamicModulesMax' directive, which would
> let us conf_vector_length = total_modules + dyn_modules_max; after the
> read_config, and finally lock down conf_vector_length = total_modules;
> at the end of post_config. WDYT?
The attached patch implements the DynamicModulesMax directive. It can appear
anywhere in the config file but is best placed *before* any LoadModule
directive. Up to post_config the number of prelinked modules plus
DynamicModulesMax is used as conf_vector_length. In core_post_config the
length is then settled on total_modules.
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
Index: server/config.c
===
--- server/config.c (revision 1094174)
+++ server/config.c (working copy)
@@ -181,22 +181,22 @@
static int total_modules = 0;
/* dynamic_modules is the number of modules that have been added
- * after the pre-loaded ones have been set up. It shouldn't be larger
- * than DYNAMIC_MODULE_LIMIT.
+ * after the pre-loaded ones have been set up. It should be at most
+ * dynamic_modules_max.
*/
static int dynamic_modules = 0;
-/* The maximum possible value for total_modules, i.e. number of static
- * modules plus DYNAMIC_MODULE_LIMIT.
+/* The maximum possible value for dynamic_modules. Shouldn't be larger than
+ * DYNAMIC_MODULE_LIMIT.
*/
-static int max_modules = 0;
+static int dynamic_modules_max;
/* The number of elements we need to alloc for config vectors. Before loading
- * of dynamic modules, we must be liberal and set this to max_modules. After
- * loading of dynamic modules, we can trim it down to total_modules. On
- * restart, reset to max_modules.
+ * of dynamic modules, we must be liberal and set this to the largest possible
+ * value (number of prelinked modules + dynamic_modules_max). After loading of
+ * dynamic modules, we can trim it down to total_modules.
*/
-static int conf_vector_length = 0;
+static int conf_vector_length;
AP_DECLARE_DATA module *ap_top_module = NULL;
AP_DECLARE_DATA module **ap_loaded_modules=NULL;
@@ -234,6 +234,22 @@
* overridden).
*/
+AP_DECLARE(void) ap_set_dynamic_modules_max(int lim)
+{
+dynamic_modules_max = lim;
+conf_vector_length = dynamic_modules_max + total_modules - dynamic_modules;
+}
+
+AP_DECLARE(int) ap_get_dynamic_modules_max(void)
+{
+return dynamic_modules_max;
+}
+
+AP_DECLARE(void) ap_settle_module_count(void)
+{
+conf_vector_length = total_modules;
+}
+
static ap_conf_vector_t *create_empty_config(apr_pool_t *p)
{
void *conf_vector = apr_pcalloc(p, sizeof(void *) * conf_vector_length);
@@ -542,7 +558,7 @@
}
if (m->module_index == -1) {
-if (dynamic_modules >= DYNAMIC_MODULE_LIMIT) {
+if (dynamic_modules >= dynamic_modules_max) {
return apr_psprintf(p, "Module \"%s\" could not be loaded, "
"because the dynamic module limit was "
"reached. Please increase "
@@ -740,8 +756,7 @@
for (m = ap_preloaded_modules; *m != NULL; m++)
(*m)->module_index = total_modules++;
-max_modules = total_modules + DYNAMIC_MODULE_LIMIT + 1;
-conf_vector_length = max_modules;
+ap_set_dynamic_modules_max(DYNAMIC_MODULE_LIMIT);
/*
* Initialise list of loaded modules and short names
@@ -2255,12 +2270,6 @@
}
-static apr_status_t reset_conf_vector_length(void *dummy)
-{
-conf_vector_length = max_modules;
-return APR_SUCCESS;
-}
-
AP_DECLARE(server_rec*) ap_read_config(process_rec *process, apr_pool_t *ptemp,
const char *filename,
ap_directive_t **conftree)
@@ -2272,6 +2281,7 @@
return s;
}
+ap_set_dynamic_modules_max(DYNAMIC_MODULE_LIMIT);
init_config_globals(p);
/* All server-wide config files now have the SAME syntax... */
@@ -2309,14 +2319,6 @@
return NULL;
}
-/*
- * We have loaded the dynamic modules. From now on we know exactly how
- * long the config vectors need to be.
- */
-conf_vector_length = total_modules;
-apr_pool_cleanup_register(p, NULL, reset_conf_vector_length,
- apr_pool_cleanup_null);
-
error = process_command_config(s, ap_server_post_read_config, conftree,
p, ptemp);
Index: server/core.c
===
--- server/core.c (revision 1094174)
+++ server/core.c (working copy)
@@ -3167,6 +3167,19 @@
}
#endif
+static const char *set_dynamic_modules_max(cmd_parms *cmd, void *dummy,
+ const char *arg)
+{
+const char *err = ap_check_
Re: Is this a test framework bug?
On Monday, April 18, 2011 10:36:13 Joe Orton wrote: > If you change the CGI script to send a 100 rather than 102, does it > work? LWP should treat all 1xx as interim responses so I'd say it is an > LWP bug. It is certainly triggered by the LWP version upgrade. I also agree that it's a bug in LWP. But my question was also what do we test here? If the purpose of the test is to see if the 102 response is passed through (as suggested by the comment) then I'd think the test is wrong too. Torsten Förtsch -- Need professional modperl support? Hire me! (http://foertsch.name) Like fantasy? http://kabatinte.net
Re: Is this a test framework bug?
On Monday, April 18, 2011 20:46:15 Stefan Fritsch wrote: > Maybe the newer LWP > sends an HTTP/1.1 request? Can you confirm this with tcpdump? Which > version of LWP do you use? At least it claims to support HTTP/1.1: GET /reverse/modules/cgi/nph-102.pl HTTP/1.1 TE: deflate,gzip;q=0.3 Connection: TE, close Host: localhost.localdomain:8538 User-Agent: libwww-perl/6.02 HTTP/1.1 102 Please Wait... Host: nph-102 HTTP/1.1 200 OK Date: Tue, 19 Apr 2011 09:01:08 GMT Server: Apache/2.3.12-dev (Unix) mod_ssl/2.3.12-dev OpenSSL/1.0.0 DAV/2 Content-Type: text/plain Connection: close Transfer-Encoding: chunked 12 this is nph-stdout 0 Torsten Förtsch -- Need professional modperl support? Hire me! (http://foertsch.name) Like fantasy? http://kabatinte.net
Re: Is this a test framework bug?
On Tuesday, April 19, 2011 10:59:45 Joe Orton wrote:
> +# force HTTP/1.0 to work around LWP 6.x bug
> +$req->protocol('HTTP/1.0');
At least for libwww-perl/6.02 that does not help. It sends HTTP/1.1 no matter
what.
Here is a way that works, although very ugly:
Index: t/modules/proxy.t
===
--- t/modules/proxy.t (revision 1094356)
+++ t/modules/proxy.t (working copy)
@@ -29,6 +29,13 @@
ok t_cmp($r->content, "abcdef", "reverse proxied to dripfeed CGI content
OK");
if (have_min_apache_version('2.1.0')) {
+# force HTTP/1.0 to work around LWP 6.x bug
+no warnings 'redefine';
+local *LWP::Protocol::http::_check_sock = sub {
+$_[2]->http_version('1.0');
+#use Data::Dumper; warn Dumper \@_, \%{*{$_[2]}};
+return;
+};
$r = GET("/reverse/modules/cgi/nph-102.pl");
ok t_cmp($r->code, 200, "reverse proxy to nph-102");
ok t_cmp($r->content, "this is nph-stdout", "reverse proxy 102
response");
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
Re: ap_read_config in 2.3.11
On Tuesday, April 19, 2011 23:35:23 Stefan Fritsch wrote:
> The attached patch adds two functions, ap_reserve_module_slots() and
> ap_reserve_module_slots_directive(), which can be called by relevant
> modules in the pre config stage.
>
> Can you please test this patch and call
> ap_reserve_module_slots_directive("PerlLoadModule") in mod_perl's
> pre_config hook?
Thanks a lot! It seems your patch works flawlessly after I figured out
another bug in the modperl test suite.
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
Problem in mod_deflate
Hi,
the DEFLATE output filter contains this piece of code (as of server magic
number 20110724)
if (!ctx) {
char *token;
const char *encoding;
/* Delay initialization until we have seen some data */
e = APR_BRIGADE_FIRST(bb);
while (1) {
apr_status_t rc;
if (e == APR_BRIGADE_SENTINEL(bb))
return ap_pass_brigade(f->next, bb);
if (APR_BUCKET_IS_EOS(e)) {
ap_remove_output_filter(f);
return ap_pass_brigade(f->next, bb);
}
if (APR_BUCKET_IS_METADATA(e))
continue;
If there is no filter context yet and the passed brigade contains only a
metadata bucket (a flush bucket for example) the "continue" statement is
hit without changing "e". Hence, it enters an infinite loop.
The last "if" statement should read as follows to avoid the loop:
if (APR_BUCKET_IS_METADATA(e)) {
e = APR_BUCKET_NEXT(e);
continue;
}
Filed as https://issues.apache.org/bugzilla/show_bug.cgi?id=51590
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
ap_send_fd ignores the offset parameter
Hi,
the trunk version of ap_send_fd always passes 0 as offset to
apr_brigade_insert_file.
Index: server/protocol.c
===
--- server/protocol.c (revision 1152467)
+++ server/protocol.c (working copy)
@@ -1380,7 +1380,7 @@
bb = apr_brigade_create(r->pool, c->bucket_alloc);
-apr_brigade_insert_file(bb, fd, 0, len, r->pool);
+apr_brigade_insert_file(bb, fd, offset, len, r->pool);
rv = ap_pass_brigade(r->output_filters, bb);
if (rv != APR_SUCCESS) {
Filed as https://issues.apache.org/bugzilla/show_bug.cgi?id=51592
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
Re: Problem in mod_deflate
Hi Stefan,
thanks for applying.
On Saturday, 30 July 2011 17:41:39 Torsten Förtsch wrote:
> The last "if" statement should read as follows to avoid the loop:
>
> if (APR_BUCKET_IS_METADATA(e)) {
> e = APR_BUCKET_NEXT(e);
> continue;
> }
I don't know how common this situation is. It came up in the modperl test
suite (t/filter/both_str_req_mix.t). This test contructs a filter chain
like
modperl filter
|
INCLUDES
|
another modperl filter
|
DEFLATE
The INCLUDES filter was passed a brigade containing a data bucket with
single SSI command like "" and a flush
bucket. mod_include then tries to find the "
Re: websocket support for mod_proxy
On Tuesday, 09 August 2011 11:48:32 Rainer Jung wrote: > Another option would be something like mod_proxy_fdpass, namely once > we observe a websocket is started, hand over the full connection via > the file descriptor to some other dedicated websocket server. I > haven't checked though, whether the mod_proxy_fdpass way of doing it > would interoperate with a Java based websocket server. A recent modperl allows to do something along these lines even with httpd 2.0, http://foertsch.name/ModPerl-Tricks/req-hand-over.shtml Torsten Förtsch -- Need professional modperl support? Hire me! (http://foertsch.name) Like fantasy? http://kabatinte.net
Bug 50861 in httpd 2.2
Hi, back in March I reported this bug: https://issues.apache.org/bugzilla/show_bug.cgi?id=50861 It got fixed in trunk but is still present in 2.2.21. Jim, according to http://www.gossamer-threads.com/lists/apache/dev/396435#396435 you thought about backporting it. How about that? Torsten Förtsch -- Need professional modperl support? Hire me! (http://foertsch.name) Like fantasy? http://kabatinte.net
Complain about revision 1162854 made by jim
Hi,
revision 1162854 fixes
https://issues.apache.org/bugzilla/show_bug.cgi?id=45076
but introduces a very similar bug.
Modperl allows to write modules in Perl. Those modules can also register
hooks. The earliest point in time when that may happen is in
ap_process_config_tree() because there are config statements that
influence certain parameters of the perl interpreter. So, we have to
process those statements prior to starting the interpreter. But only the
perl interpreter knows which modules to load. Those modules then can
install hooks. But with revision 1162854 these hooks are called out of
order.
With the enclosed patch apr_hook_sort_all() is called once before
ap_run_pre_config() and then again after ap_process_config_tree().
The patch applies to 2.2.21 but the same change was made to trunk as
well. So, please apply it there too.
I'll reopen bug 45076.
Thanks,
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
--- server/main.c.orig 2011-10-07 19:18:13.395926482 +0200
+++ server/main.c 2011-10-07 19:25:18.985699364 +0200
@@ -633,6 +633,8 @@
if (!server_conf) {
destroy_and_exit_process(process, 1);
}
+/* sort hooks here to make sure pre_config hooks are sorted properly
+ */
apr_hook_sort_all();
if (ap_run_pre_config(pconf, plog, ptemp) != OK) {
@@ -646,6 +648,10 @@
if (rv == OK) {
ap_fixup_virtual_hosts(pconf, server_conf);
ap_fini_vhost_config(pconf, server_conf);
+/* sort hooks again b/c ap_process_config_tree might add modules and
+ * hence hooks.
+ */
+apr_hook_sort_all();
if (configtestonly) {
ap_run_test_config(pconf, server_conf);
@@ -704,6 +710,8 @@
if (!server_conf) {
destroy_and_exit_process(process, 1);
}
+/* sort hooks here to make sure pre_config hooks are sorted properly
+ */
apr_hook_sort_all();
if (ap_run_pre_config(pconf, plog, ptemp) != OK) {
@@ -718,6 +726,10 @@
}
ap_fixup_virtual_hosts(pconf, server_conf);
ap_fini_vhost_config(pconf, server_conf);
+/* sort hooks again b/c ap_process_config_tree might add modules and
+ * hence hooks.
+ */
+apr_hook_sort_all();
apr_pool_clear(plog);
if (ap_run_open_logs(pconf, plog, ptemp, server_conf) != OK) {
ap_log_error(APLOG_MARK, APLOG_STARTUP |APLOG_ERR,
Re: Silencing the "NameVirtualHost has no effect..." warning in Apache::Test
On Sunday, 09 October 2011 19:10:15 Stefan Fritsch wrote: > On Tuesday 04 October 2011, Kaspar Brand wrote: > > As of 2.3.11, httpd emits a warning when NameVirtualHost is still > > present in the config (cf. > > http://svn.apache.org/viewvc?view=revision&revision=1053230). > > > > > > > > Can we silence that warning for the default test config? A small > > change to TestConfig.pm in Apache::Test is needed... something > > like the attached patch. Could someone with the proper karma have > > a look (and commit to perl/Apache-Test/trunk, possibly)? > > The patch looks OK to me. I think you have commit rights there. If > not, you should have. Can you try, please? If nobody beats me I'll try it out and commit it tomorrow. Torsten Förtsch -- Need professional modperl support? Hire me! (http://foertsch.name) Like fantasy? http://kabatinte.net
Re: Silencing the "NameVirtualHost has no effect..." warning in Apache::Test
On Tuesday, 04 October 2011 09:27:50 Kaspar Brand wrote: > As of 2.3.11, httpd emits a warning when NameVirtualHost is still > present in the config (cf. > http://svn.apache.org/viewvc?view=revision&revision=1053230). > > Can we silence that warning for the default test config? A small > change to TestConfig.pm in Apache::Test is needed... something like > the attached patch. Could someone with the proper karma have a look > (and commit to perl/Apache-Test/trunk, possibly)? Thanks, applied as r1180971. Torsten Förtsch -- Need professional modperl support? Hire me! (http://foertsch.name) Like fantasy? http://kabatinte.net
Re: Server Process Pool Behavior
On Friday, 11 November 2011 20:09:09 Jason Gionta wrote: > While I expect the count to increment by one after each request. It > seems like if there is a time gap between requests (over 10 seconds), > the count gets reset (apr_hash_count = 0). May it be that your requests simply hit another worker process? Torsten Förtsch -- Need professional modperl support? Hire me! (http://foertsch.name) Like fantasy? http://kabatinte.net
APR_POOL_DEBUG
Hi, I have just compiled apr 1.4.5 with -DAPR_POOL_DEBUG=0x1f and --enable-threads. Is this a valid configuration? Is it supposed to survive "make check"? "make check" first calls ./testlockperf which succeeds. Then comes ./testmutexscope which fails. Called manually it says: POOL DEBUG: [PID/TID] ACTION (SIZE /POOL SIZE /TOTAL SIZE) POOL "TAG" <__FILE__:__LINE__> (ALLOCS/TOTAL ALLOCS/CLEARS) POOL DEBUG: [9305/140618473854784] GLOBAL 0x604010 POOL DEBUG: [9305/140618473854784] CREATE ( 0/ 0/ 200) 0x6045c0 "misc/unix/start.c:58" (0/0/0) Trying proc mutexes with mechanism `default'... POOL DEBUG: [9305/140618473854784] CREATE ( 0/ 0/ 200) 0x604660 "testmutexscope.c:116" (0/0/0) POOL DEBUG: [9305/140618473854784] PCALLOC (48/48/ 248) 0x604660 "testmutexscope.c:116" (1/1/0) POOL DEBUG: [9305/140618473854784] PALLOC (80/80/ 280) 0x604660 "testmutexscope.c:116" (2/2/0) POOL DEBUG: [9305/140618473854784] PCALLOC ( 144/ 144/ 344) 0x604660 "testmutexscope.c:116" (3/3/0) POOL DEBUG: [9305/140618473854784] PALLOC ( 264/ 264/ 464) 0x604660 "testmutexscope.c:116" (4/4/0) POOL DEBUG: [9305/140618473854784] PALLOC ( 296/ 296/ 496) 0x604660 "testmutexscope.c:116" (5/5/0) POOL DEBUG: [9305/140618473854784] PCALLOC ( 336/ 336/ 536) 0x604660 "testmutexscope.c:116" (6/6/0) POOL DEBUG: [9305/140618473854784] PCALLOC ( 344/ 344/ 544) 0x604660 "testmutexscope.c:116" (7/7/0) POOL DEBUG: [9305/140618473854784] CREATE ( 0/ 0/ 544) 0x604ce0 "threadproc/unix/thread.c:174" (0/0/0) POOL DEBUG: [9305/140618473854784] PCALLOC ( 384/ 384/ 584) 0x604660 "testmutexscope.c:116" (8/8/0) POOL DEBUG: [9305/140618473854784] PCALLOC ( 392/ 392/ 592) 0x604660 "testmutexscope.c:116" (9/9/0) POOL DEBUG: [9305/140618473854784] CREATE ( 0/ 0/ 592) 0x604f00 "threadproc/unix/thread.c:174" (0/0/0) POOL DEBUG: [9305/140618473854784] PCALLOC ( 432/ 432/ 632) 0x604660 "testmutexscope.c:116" (10/10/0) POOL DEBUG: [9305/140618473854784] PCALLOC ( 440/ 440/ 640) 0x604660 "testmutexscope.c:116" (11/11/0) POOL DEBUG: [9305/140618473854784] CREATE ( 0/ 0/ 640) 0x605120 "threadproc/unix/thread.c:174" (0/0/0) POOL DEBUG: [9305/140618473854784] PCALLOC ( 480/ 480/ 680) 0x604660 "testmutexscope.c:116" (12/12/0) POOL DEBUG: [9305/140618473854784] PCALLOC ( 488/ 488/ 688) 0x604660 "testmutexscope.c:116" (13/13/0) POOL DEBUG: [9305/140618473854784] CREATE ( 0/ 0/ 688) 0x605340 "threadproc/unix/thread.c:174" (0/0/0) POOL DEBUG: [9305/140618473854784] PCALLOC ( 528/ 528/ 728) 0x604660 "testmutexscope.c:116" (14/14/0) POOL DEBUG: [9305/140618473854784] PCALLOC ( 536/ 536/ 736) 0x604660 "testmutexscope.c:116" (15/15/0) POOL DEBUG: [9305/140618473854784] CREATE ( 0/ 0/ 736) 0x605560 "threadproc/unix/thread.c:174" (0/0/0) Mutex mechanism `default' is global in scope on this platform. POOL DEBUG: [9305/140618454791936] THREAD 0x604ce0 POOL DEBUG: [9305/140618421221120] THREAD 0x605560 POOL DEBUG: [9305/140618438006528] THREAD 0x605120 POOL DEBUG: [9305/140618429613824] THREAD 0x605340 POOL DEBUG: [9305/140618446399232] THREAD 0x604f00 Aborted Torsten Förtsch -- Need professional modperl support? Hire me! (http://foertsch.name) Like fantasy? http://kabatinte.net
idea: faster pool user data
Hi, I have just subscribed to the apr-list because http://apr.apache.org/mailing- lists.html says: If you have patches or suggestions, feel free to share them with this list. For quite a time now I have this idea how a certain type of pool user data can be made faster. It would require specialized pools. That means a request pool is still a pool but different from a connection pool or a process pool in httpd. For each type of pool we have a next_free_array_index integer variable. Further, there is an API function to allocate such an index that simply increments the next_free_array_index per-pool-type variable and returns the previous value. Also, the type definition of an apr_pool_t is to be extented by an apr_array_header_t. Now, at initialization time a user can allocate an index for a certain pool type. Then, when a pool of a certain type is created the an array of void* of length next_free_array_index for that pool type is created and initialized with NULL. The user then can do with his own array slot what he wants. My current need for something similar is as follows. Modperl allows Perl modules to create custom HTTPD configuration directives. Those directives then are merged at runtime with the server's base config. For this merge a Perl interpreter is needed which is found in a threaded environment by means of r->server. But the merge function is passed only the request pool not the request_rec. So, for each request I store the request_rec as pool user data with the request pool. This solution works but is suboptimal because even if nothing modperl-related is used for the whole request I need to store the request_rec in the userdata hash because the merge may be the first operation that needs a perl interpreter. With the new technique I could at init time in the parent httpd static int my_req_pool_data; ... my_req_pool_data=apr_pool_userdata_allocate_slot(AP_POOL_TYPE_REQ); And then at runtime when the request is initialized: *apr_pool_userdata_by_slot(r->pool, my_req_pool_data)=r; To fetch the request_rec associated with the pool: r=*apr_pool_userdata_by_slot(p, my_req_pool_data); The apr_pool_userdata_by_slot operation is then basically an array lookup which is much cheaper than the hash lookup now. Has something similar already been discussed? Is it worth thinking about? Are there other options that I perhaps don't know about yet to achieve something similar? Thanks for reading, Torsten Förtsch -- Need professional modperl support? Hire me! (http://foertsch.name) Like fantasy? http://kabatinte.net
Is it intentional that the Timeout must hit twice for a CGI script to be killed?
Hi,
cgi_handler() in 2.2 contains these lines. For trunk they look very similar.
if (!nph) {
const char *location;
char sbuf[MAX_STRING_LEN];
int ret;
if ((ret = ap_scan_script_header_err_brigade(r, bb, sbuf))) {
ret = log_script(r, conf, ret, dbuf, sbuf, bb, script_err);
Now, if the script does not generate any output not even headers
ap_scan_script_header_err_brigade() polls the script's stdout and stderr
until the timeout is reached. Then log_script() is called which calls
discard_script_output() and, thus, again ends up in cgi_bucket_read()
waiting for the second timeout.
Is that intentional?
Torsten
mod_include patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi.
I want to use SSI with CGI scripts. Thus, I have configured the INCLUDES
filter for my cgi-bin. But my CGI scripts generate not only text/html
documents. Hence my problem, I want to say mod_include to handle only
documents with content-type text/html even if the content-type is changed by
the response phase.
This is impossible with the existing mod_include. The only check the
mod_include filter routine performs is whether Includes option is given. All
content-type checks/changes are done in the fixup phase which is too early
for a CGI script that wants to print a content-type header.
The attached patch defines a new configuration directive SSIAllowedType that
can be assigned a content-type:
SSIAllowedType text/html
If given only documents of that content-type are subject for SSI.
What do I have to do to get this patch included in standard mod_include?
Torsten
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBdpGZwicyCTir8T4RAvEkAJ9T9czprZChc7QMADZjSR07L6mAqwCfdUNl
/zFal2FEkTuX+5vugm1q1N4=
=uttx
-END PGP SIGNATURE-
--- httpd-2.0.52/modules/filters/mod_include.c~ 2004-08-27 21:41:22.0 +0200
+++ httpd-2.0.52/modules/filters/mod_include.c 2004-10-19 20:18:25.716502656 +0200
@@ -72,6 +72,7 @@
} ;
typedef struct {
+char *allowed_type;
char *default_error_msg;
char *default_time_fmt;
enum xbithack *xbithack;
@@ -3400,6 +3401,7 @@
(include_dir_config *)apr_palloc(p, sizeof(include_dir_config));
enum xbithack *xbh = (enum xbithack *) apr_palloc(p, sizeof(enum xbithack));
*xbh = DEFAULT_XBITHACK;
+result->allowed_type = NULL;
result->default_error_msg = DEFAULT_ERROR_MSG;
result->default_time_fmt = DEFAULT_TIME_FORMAT;
result->xbithack = xbh;
@@ -3479,15 +3481,24 @@
include_server_config *sconf= ap_get_module_config(r->server->module_config,
&include_module);
-if (!(ap_allow_options(r) & OPT_INCLUDES)) {
-ap_log_rerror(APLOG_MARK, APLOG_WARNING, 0, r,
- "mod_include: Options +Includes (or IncludesNoExec) "
- "wasn't set, INCLUDES filter removed");
-ap_remove_output_filter(f);
-return ap_pass_brigade(f->next, b);
-}
-
if (!f->ctx) {
+if (conf->allowed_type &&
+ (!r->content_type || strcmp(r->content_type, conf->allowed_type))) {
+ ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
+ "mod_include: Content-Type is %s, "
+ "INCLUDES filter removed", r->content_type);
+ ap_remove_output_filter(f);
+ return ap_pass_brigade(f->next, b);
+ }
+
+ if (!(ap_allow_options(r) & OPT_INCLUDES)) {
+ ap_log_rerror(APLOG_MARK, APLOG_WARNING, 0, r,
+ "mod_include: Options +Includes (or IncludesNoExec) "
+ "wasn't set, INCLUDES filter removed");
+ ap_remove_output_filter(f);
+ return ap_pass_brigade(f->next, b);
+ }
+
/* create context for this filter */
f->ctx = ctx = apr_palloc(f->c->pool, sizeof(*ctx));
ctx->ctx = apr_pcalloc(f->c->pool, sizeof(*ctx->ctx));
@@ -3618,6 +3629,13 @@
return OK;
}
+static const char *set_allowed_type(cmd_parms *cmd, void *mconfig, const char *msg)
+{
+include_dir_config *conf = (include_dir_config *)mconfig;
+conf->allowed_type = apr_pstrdup(cmd->pool, msg);
+return NULL;
+}
+
static const char *set_default_error_msg(cmd_parms *cmd, void *mconfig, const char *msg)
{
include_dir_config *conf = (include_dir_config *)mconfig;
@@ -3680,6 +3698,8 @@
"SSI End String Tag"),
AP_INIT_TAKE1("SSIUndefinedEcho", set_undefined_echo, NULL, RSRC_CONF,
"SSI Start String Tag"),
+AP_INIT_TAKE1("SSIAllowedType", set_allowed_type, NULL, OR_ALL,
+ "allow INCLUDES filter only for this content-type"),
{NULL}
};
Re: mod_include patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 20 October 2004 18:49, André Malo wrote: > > I want to use SSI with CGI scripts. Thus, I have configured the INCLUDES > > filter for my cgi-bin. But my CGI scripts generate not only text/html > > documents. Hence my problem, I want to say mod_include to handle only > > documents with content-type text/html even if the content-type is changed > > by the response phase. > > Why don't you just use addoutputfilterbytype? because I am using another mod_perl output filter that should be called *after* INCLUDES. There is a PerlSetOutputFilter directive that preserves filter ordering but it adds the filter unconditionally. Torsten -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBd1TDwicyCTir8T4RAjYyAJ0ZHNaRnXX+tMU7YZx6urYEtLZDJgCdGqFE cfnrLnwvtnd0ZYOju1j/Zqk= =KqMr -END PGP SIGNATURE-
