Re: SSL unexpected renegotiation for CGI with PATH_INFO
On Mon 07 Dec 2009, Masaoki Kobayashi wrote:
I found suspicious behavior with CGI using PATH_INFO when
it is on the client authenticated SSL.
My situation is as follows.
/foo
SSLVerifyClient none
/bar
SSLVerifyClient require
Assume here're some files under /foo.
a.html - plain html file
b.cgi - regular cgi (not nph)
Then, I get somes file from browser.
What I could get without certificates are...
/foo/a.html
/foo/b.cgi
/foo/b.cgi/foo --- (1)
What SSL session renegotiation runs, so I needed certificates
to access are...
/bar
/foo/b.cgi/bar --- (2)
Because /foo is configured as SSLVerifyClient none, so I expect
it does not need any certificates.
What is different between (1) and (2)?
I could see the request is processed twice because the second
request (protocol=INCLUDED) is generated in ap_add_cgi_vars().
The second request issued with uri=path_info, so that it makes
SSL renegotiation only when path_info is under /bar.
util_script.c
370 if (r-path_info r-path_info[0]) {
371 /*
372 * To get PATH_TRANSLATED, treat PATH_INFO as a URI path.
373 * Need to re-escape it for this, since the entire URI was
374 * un-escaped before we determined where the PATH_INFO
began. 375 */
376 request_rec *pa_req;
377
378 pa_req = ap_sub_req_lookup_uri(ap_escape_uri(r-pool,
r-path_info), r, 379 NULL);
Does someone have any idea for this?
This is another occurrence of bug #48228. Mod_cgi tries to map PATH_INFO
to the file system to set an environment variable using a subrequest.
This subrequest then triggers renegotiation.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48228
Torsten
--
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net
Re: TLS renegotiation disabling : mod_ssl and OpenSSL 0.9.8l
On Mon 16 Nov 2009, Jean-Marc Desperrier wrote: Here's the wireshark captured exchange between the client and server, note that Hello Request always *immediatly* follows the end of the renegotiation. This is with Apache 2.2.11/Openssl 0.9.8i (not a production server) : 217 19:30:50.745606 client_ip server_ip HTTPGET /authentication/ HTTP/1.1 218 19:30:50.747473 server_ip client_ip TLSv1 Hello Request 219 19:30:50.747896 client_ip server_ip TLSv1 Clien t Hello 220 19:30:50.749114 server_ip client_ip TLSv1 Serve r Hello, Certificate, Certificate Request, Server Hello Done 257 19:30:59.267340 client_ip server_ip TLSv1 Certi ficate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Finished 259 19:30:59.288262 server_ip client_ip TLSv1 Chang e Cipher Spec, Finished 260 19:30:59.289066 server_ip client_ip TLSv1 Hello Request 262 19:30:59.289511 client_ip server_ip TLSv1 Clien t Hello ... 510 19:31:37.260057 server_ip client_ip HTTPHTTP/ 1.1 200 OK (text/html) I have noticed something similar. Don't know if it applies to you. If your /authentication/ is a resource that generates a directory listing via mod_autoindex then apache issues a subrequest for each directory entry. Now, if only /authentication/ requires a client certificate but the VHost or base server does not then each entry leads to a renegotiation. Correct me if I am wrong but that is how I have explained the behavior for me. Torsten -- Need professional mod_perl support? Just hire me: torsten.foert...@gmx.net
Re: mod_reqtimeout: mitigating against slowloris-style attack (different approach)
On Tue 01 Sep 2009, Stefan Fritsch wrote: http://www.sfritsch.de/mod_reqtimeout/mod_reqtimeout.c Any comments are welcome. Just a few thoughts: - You use GLOBAL_ONLY in ap_check_cmd_context. That means the directive must not appear in vhost context. AFAIK, conn-base_server reflects the vhost in a pre connection hook if it is IP-based. So, why don't you allow for RequestTimeout to be valid in ip-based vhost context? That way the protocol problem is solved, isn't it? - Wouldn't RequestTimeout better be named RequestHeaderTimeout or ReadRequestHeaderTimeout? RequestTimeout is a bit missleading (IMHO). My first thought was: That thing limits the whole transaction. - You mentioned a minimum body transfer rate instead of a simple timeout. If the default values for LimitRequestFields, LimitRequestFieldSize and LimitRequestLine are added up I get a max. request header size of 101*8190 bytes. This may take some time to transmit while still valid. So, perhaps a transfer rate limit for the header is a good option, as well. Perhaps having both a timeout and a rate limit would be good. Just my 0.02€. Torsten -- Need professional mod_perl support? Just hire me: torsten.foert...@gmx.net
Re: svn commit: r773881 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS include/http_core.h modules/filters/mod_include.c server/config.c server/core.c
On Fri 22 May 2009, Jeff Trawick wrote: Hmmm, after trying to use what seems like a cool feature, I find that mod_perl was never taught to use the Apache 2's mod_include plug-in interface. AFAIK, that is provided by Geoff's CPAN module Apache::IncludeHook or so. Torsten -- Need professional mod_perl support? Just hire me: torsten.foert...@gmx.net
Re: State of Apache::Test?
On Wed 15 Apr 2009, Dan Poirier wrote: I'm wondering - what's the state of Apache::Test and httpd/test? Are there active developers using them who understand how they work? Or have they fallen into disuse? Background: I wanted to see if I could write some tests for the new SNI features, so I started looking at Apache::Test. Unfortunately it's been some years since I had my head deep into the Perl way of doing things, and even after looking over the documentation, I think it would take me a long time to get to the point where I could write new tests there. The modperl users list modp...@perl.apache.org is for you. I think you'll find answers very shortly. Torsten -- Need professional mod_perl support? Just hire me: torsten.foert...@gmx.net
Re: 2.2.11 mod_include
On Wed 01 Apr 2009, Dan Poirier wrote:
Lars Eilebrecht l...@eilebrecht.net writes:
Torsten Foertsch wrote:
[mod_include DATE_LOCAL bug]
Is this a known bug?
It's probably this one:
https://issues.apache.org/bugzilla/show_bug.cgi?id=39369
I think that's right. It's a test for Joe's fix for 39369, that has
only been applied to trunk. It would be nice to backport that fix so
the stable release doesn't fail tests (or else do something with that
test).
Here is a patch that works for 2.2.11. The mod_rerwite patch cures the
failure in t/modules/rewrite.t:
https://issues.apache.org/bugzilla/show_bug.cgi?id=46428
in 2.2.11.
The mod_info problem in my original mail was caused by my local setup
and is rather a Apache::Test problem (if at all). I have 2 modperl
versions installed, mod_perl-debug.so and mod_perl.so. That has
confused the test.
Should I attach these patches to the problem reports in bugzilla or is
that useless because they wont be backported officially?
Torsten
--
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net
--- modules/mappers/mod_rewrite.c.xx 2009-04-01 11:28:01.0 +0200
+++ modules/mappers/mod_rewrite.c 2009-04-01 11:35:28.0 +0200
@@ -3869,7 +3869,20 @@
* ourself).
*/
if (p-flags RULEFLAG_PROXY) {
- /* PR#39746: Escaping things here gets repeated in mod_proxy */
+/* For rules evaluated in server context, the mod_proxy fixup
+ * hook can be relied upon to escape the URI as and when
+ * necessary, since it occurs later. If in directory context,
+ * the ordering of the fixup hooks is forced such that
+ * mod_proxy comes first, so the URI must be escaped here
+ * instead. See PR 39746, 46428, and other headaches. */
+if (ctx-perdir (p-flags RULEFLAG_NOESCAPE) == 0) {
+char *old_filename = r-filename;
+
+r-filename = ap_escape_uri(r-pool, r-filename);
+rewritelog((r, 2, ctx-perdir, escaped URI in per-dir context
+for proxy, %s - %s, old_filename, r-filename));
+}
+
fully_qualify_uri(r);
rewritelog((r, 2, ctx-perdir, forcing proxy-throughput with %s,
--- modules/filters/mod_include.c.orig 2008-03-17 15:32:47.0 +0100
+++ modules/filters/mod_include.c 2009-04-01 14:45:41.0 +0200
@@ -580,7 +580,7 @@
*p = '\0';
}
-static void add_include_vars(request_rec *r, const char *timefmt)
+static void add_include_vars(request_rec *r)
{
apr_table_t *e = r-subprocess_env;
char *t;
@@ -608,26 +608,17 @@
}
}
-static const char *add_include_vars_lazy(request_rec *r, const char *var)
+static const char *add_include_vars_lazy(request_rec *r, const char *var, const char *timefmt)
{
char *val;
if (!strcasecmp(var, DATE_LOCAL)) {
-include_dir_config *conf =
-(include_dir_config *)ap_get_module_config(r-per_dir_config,
- include_module);
-val = ap_ht_time(r-pool, r-request_time, conf-default_time_fmt, 0);
+val = ap_ht_time(r-pool, r-request_time, timefmt, 0);
}
else if (!strcasecmp(var, DATE_GMT)) {
-include_dir_config *conf =
-(include_dir_config *)ap_get_module_config(r-per_dir_config,
- include_module);
-val = ap_ht_time(r-pool, r-request_time, conf-default_time_fmt, 1);
+val = ap_ht_time(r-pool, r-request_time, timefmt, 1);
}
else if (!strcasecmp(var, LAST_MODIFIED)) {
-include_dir_config *conf =
-(include_dir_config *)ap_get_module_config(r-per_dir_config,
- include_module);
-val = ap_ht_time(r-pool, r-finfo.mtime, conf-default_time_fmt, 0);
+val = ap_ht_time(r-pool, r-finfo.mtime, timefmt, 0);
}
else if (!strcasecmp(var, USER_NAME)) {
if (apr_uid_name_get(val, r-finfo.user, r-pool) != APR_SUCCESS) {
@@ -684,7 +675,7 @@
val = apr_table_get(r-subprocess_env, var);
if (val == LAZY_VALUE) {
-val = add_include_vars_lazy(r, var);
+val = add_include_vars_lazy(r, var, ctx-time_str);
}
}
@@ -2423,7 +2414,7 @@
/* get value */
val_text = elts[i].val;
if (val_text == LAZY_VALUE) {
-val_text = add_include_vars_lazy(r, elts[i].key);
+val_text = add_include_vars_lazy(r, elts[i].key, ctx-time_str);
}
val_text = ap_escape_html(ctx-dpool, elts[i].val);
v_len = strlen(val_text);
@@ -3608,7 +3599,7 @@
* environment */
ap_add_common_vars(r);
ap_add_cgi_vars(r);
-add_include_vars(r, conf-default_time_fmt);
+add_include_vars(r);
}
/* Always unset the content-length. There is no way to know if
* the content will be modified
Re: mod_include supporting POST subrequests
On Fri 20 Mar 2009, Graham Leggett wrote:
Torsten Foertsch wrote:
I need the include virtual directive to be able to issue POST
requests. It should pass the request body to the subrequest. So I
came up with the attached patch.
It allows to write
!--#include method=post virtual=... -- or
!--#include method=inherit virtual=... --
[...]
Something like this has already been added to trunk, take a look at
the KEEP_BODY and KEPT_BODY filters in modules/filters/mod_request.c.
I did and, frankly, it is not the solution I was looking for. One has to
define a max. body size to be kept. The body is kept in RAM which can
be a problem unless KeptBodySize is rather small. So I developed my
patch further.
It defers now the ap_discard_request_body call as much as possible. This
gives output filters the chance to read the req body. If the client is
expecting a 100 Continue message it is sent just before the first
line of output.
Is there a chance for the patch to make it into 2.3++? If yes I'll merge
it with the KEPT_BODY stuff.
Currently my httpd passes the current test framework with a few more
patches that are not related to this one (see 2.2.11 mod_include
thread) with one exception. Since the request body is read when output
is potentially already on the wire a HTTP_REQUEST_ENTITY_TOO_LARGE
error cannot be sent to the client if it sends the request body in
chunked TE. The only sensible solution that I can think of would be to
always send a 413 response if TE is chunked and a LimitRequestBody is
active.
On Fri 20 Mar 2009, Nick Kew wrote:
Erm ... that's ringing alarm bells. The client, not the
server, determines HTTP methods. Or are you talking about
proxied subrequests here?
I see it a bit different. Subrequests for included documents are made on
behalf of the HTML programmer who wrote the frame. He decides to pass
on the request body and he decides which method to use, IMHO. And yes,
the problem comes from subrequests that are proxied to another server.
Torsten
--
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net
--- modules/filters/mod_include.c.orig 2008-03-17 15:32:47.0 +0100
+++ modules/filters/mod_include.c 2009-03-25 14:49:14.0 +0100
@@ -1656,6 +1656,7 @@
apr_bucket_brigade *bb)
{
request_rec *r = f-r;
+enum {METHOD_GET, METHOD_POST, METHOD_INHERIT} method;
if (!ctx-argc) {
ap_log_rerror(APLOG_MARK,
@@ -1674,6 +1675,8 @@
return APR_SUCCESS;
}
+method=METHOD_GET;
+
while (1) {
char *tag = NULL;
char *tag_val = NULL;
@@ -1686,6 +1689,29 @@
break;
}
+if (tag[0] == 'm' !strcmp(tag, method)) {
+if ((tag_val[0] == 'g' || tag_val[0] == 'G')
+ !strcasecmp(tag_val, get)) {
+method=METHOD_GET;
+}
+else if ((tag_val[0] == 'p' || tag_val[0] == 'P')
+ !strcasecmp(tag_val, post)) {
+method=METHOD_POST;
+}
+else if ((tag_val[0] == 'i' || tag_val[0] == 'I')
+ !strcasecmp(tag_val, inherit)) {
+method=METHOD_INHERIT;
+}
+else {
+ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, unknown value
+ \%s\ to parameter \method\ of tag
+ include in %s, tag_val, r-filename);
+SSI_CREATE_ERROR_BUCKET(ctx, f, bb);
+break;
+}
+continue;
+}
+
if (strcmp(tag, virtual) strcmp(tag, file)) {
ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, unknown parameter
\%s\ to tag include in %s, tag, r-filename);
@@ -1712,7 +1738,15 @@
}
}
else {
-rr = ap_sub_req_lookup_uri(parsed_string, r, f-next);
+if (method == METHOD_GET
+|| (method == METHOD_INHERIT strcmp(r-method, POST))) {
+rr = ap_sub_req_lookup_uri(parsed_string, r, f-next);
+}
+else { /* POST */
+method = METHOD_POST;
+apr_table_setn(r-notes, subreq-pass-request-body, 1);
+rr = ap_sub_req_method_uri(POST, parsed_string, r, f-next);
+}
}
if (!error_fmt rr-status != HTTP_OK) {
@@ -1734,10 +1768,22 @@
ap_set_module_config(rr-request_config, include_module, r);
}
+/* XXX: would be good to check for EOS on rr-input_filters
+ * if method==POST and issue a warning if so.
+ */
+
if (!error_fmt ap_run_sub_req(rr)) {
error_fmt = unable to include \%s\ in parsed file %s;
}
+/* method=POST must be specified *before* *each*
+ * virtual=...
+ */
+if (method != METHOD_GET) {
+method = METHOD_GET
Re: mod_include supporting POST subrequests
On Wed 01 Apr 2009, Graham Leggett wrote: Is there a chance for the patch to make it into 2.3++? If yes I'll merge it with the KEPT_BODY stuff. Having two separate mechanisms to solve the same problem is not ideal. In addition, creating a solution that only works in one place (mod_include), is less ideal still. It should be relatively straightforward to amend the KEEP_BODY and KEPT_BODY filters so that, by default, the first attempt to read the body is passed through, and the second and subsequent attempts to read the body return an empty brigade. This will give you the behaviour you are looking for, and it will work anywhere within the server, not just in mod_include. That is what I thought to do. If KeptBodySize is 0 the body is passed to the first (sub)request that is reading it. All subsequent subrequests will see an empty stream. If KeptBodySize is 0 the first (sub)request reads the whole body and the KEEP_BODY_FILTER saves as much as is configured. Subsequent subrequests are passed this kept body. I also thought of writing the body to temporary files if configured. So it's possible to preserve larger body without much headache about memory consumption. Plus, I think it would be a nice feature to be able to !--#include method=post body=a=b;c=d virtual=... -- and perhaps also to include an encoding=multipart/form-data, would it not? BTW, the current patch is not only for mod_include. It should work (although not tested) for other filters/handlers as well as long as the main request sets the subreq-pass-request-body note to prevent the header table to be overwritten for the subrequest. This more or less resembles what r-kept_body does in 2.3. Alternatively the caller could overwrite the header table after creating the subreq but before running it and set the original CL and TE headers. But to restate my question, can I take your reply as yes, go ahead, it would be nice to have that feature in apache httpd? Torsten -- Need professional mod_perl support? Just hire me: torsten.foert...@gmx.net
2.2.11 mod_include
Hi,
my apache 2.2.11 does not pass the current httpd test framework:
t/modules/include.t (Wstat: 0 Tests: 88 Failed: 1)
Failed test: 67
t/modules/info.t (Wstat: 0 Tests: 1 Failed: 1)
Failed test: 1
t/modules/rewrite.t (Wstat: 0 Tests: 29 Failed: 1)
Failed test: 24
At least for the first failure I have found a reason. The test file that
should be parsed by the includes filter looks:
!--#config timefmt=%Y --
xx!--#echo var=DATE_LOCAL --xx
But in the output DATE_LOCAL is printed as Tuesday, 31-Mar-2009
17:09:45 CEST.
The problem is the INCLUDES filter is inserted twice, once by mod_mime
for the .shtml extension:
#0 ap_add_output_filter (name=0xb747b8 includes, ctx=0x0, r=0xb76548,
c=0xb646a8) at util_filter.c:422
#1 0x7fdbfb36cf11 in find_ct (r=0xb76548) at mod_mime.c:876
#2 0x00436ce3 in ap_run_type_checker (r=0xb76548) at request.c:75
and a second time by mod_include in
#0 ap_add_output_filter (name=0x7fdbfe836b85 INCLUDES, ctx=0x0, r=0xb76548,
c=0xb646a8) at util_filter.c:422
#1 0x7fdbfe8322da in include_fixup (r=0xb76548) at mod_include.c:3738
#2 0x00436c1a in ap_run_fixups (r=0xb76548) at request.c:73
Thus the first filter in the chain handles the timefmt correctly and
sets DATE_LOCAL in r-subprocess_env. But the 2nd filter overwrites this
value in add_include_vars() called here:
static apr_status_t includes_filter(ap_filter_t *f, apr_bucket_brigade *b)
{
...
if ((parent = ap_get_module_config(r-request_config, include_module))) {
/* Kludge --- for nested includes, we want to keep the subprocess
* environment of the base document (for compatibility); that means
* torquing our own last_modified date as well so that the
* LAST_MODIFIED variable gets reset to the proper value if the
* nested document resets !--#config timefmt --.
*/
r-subprocess_env = r-main-subprocess_env;
apr_pool_join(r-main-pool, r-pool);
r-finfo.mtime = r-main-finfo.mtime;
}
else {
/* we're not a nested include, so we create an initial
* environment */
ap_add_common_vars(r);
ap_add_cgi_vars(r);
add_include_vars(r, conf-default_time_fmt); -- here
}
...
Is this a known bug?
Torsten
--
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net
http_in filter question
Hi,
the http_in filter (ap_http_filter) uses an eos_sent flag in its
context. This flag is set each time an eos bucket is sent except for
one case:
/* If we have no more bytes remaining on a C-L request,
* save the callter a roundtrip to discover EOS.
*/
if (ctx-state == BODY_LENGTH ctx-remaining == 0) {
e = apr_bucket_eos_create(f-c-bucket_alloc);
APR_BRIGADE_INSERT_TAIL(b, e);
}
Is that a typo? If not, why is it omitted here?
Shouldn't that piece read:
/* If we have no more bytes remaining on a C-L request,
* save the callter a roundtrip to discover EOS.
*/
if (ctx-state == BODY_LENGTH ctx-remaining == 0) {
e = apr_bucket_eos_create(f-c-bucket_alloc);
APR_BRIGADE_INSERT_TAIL(b, e);
ctx-eos_sent = 1;
}
Torsten
--
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net
mod_include supporting POST subrequests
Hi,
I need the include virtual directive to be able to issue POST requests.
It should pass the request body to the subrequest. So I came up with
the attached patch.
It allows to write
!--#include method=post virtual=... -- or
!--#include method=inherit virtual=... --
I think the patch is right so far but I wouldn't mind if some more
experienced eyes had a look.
One problem remains. What if the HTML author uses that method=post thing
twice? The first call has consumed the post body. The second will try
to read something but the client has already sent all it can.
Hence, I'd like to
if (!eof_on_input()) {
rr-headers_in = r-headers_in;
}
How can I determine if the request body for the current request has
already been consumed?
Is there a chance that a patch like this will be accepted for inclusion
in apache?
Torsten
--
Need professional mod_perl support?
Just hire me: torsten.foert...@gmx.net
Re: Open Projects
On Fri 06 Mar 2009, ntwrkd wrote: What portions of the httpd project need work/bug fixes? Is there a top priorities page I can view? Thx Don't know if there is a list. But mod_perl and libapreq (I think) could use a hand if you are interested. Torsten -- Need professional mod_perl support? Just hire me: torsten.foert...@gmx.net
Re: [RELEASE CANDIDATE] libapreq2 2.11
On Wed 28 Jan 2009, Issac Goldstand wrote: Vote results show only 2 +1s (issac,joes) and no -1s. We're still a +1 short of release. If it matters, I have successfully run all tests on my mod_perl installation (threading branch) with apache 2.2.11 both with worker and prefork on Suse linux 11.1 (perl 5.10). But I am not a heavy user. Apache/2.2.11 (Unix) proxy_html/3.0.1 mod_ssl/2.2.11 OpenSSL/0.9.8h DAV/2 SVN/1.5.5 mod_apreq2-20090110/2.7.0 mod_perl/2.0.5threading2 Perl/v5.10.0 The only thing that confuses me is the version string 2.7.0 while the TAR file is named 2.11. Torsten -- Need professional mod_perl support? Just hire me: torsten.foert...@gmx.net
Scoreboard question
Hi, I am working on a monitoring tool that works independently from apache and analyzes the scoreboard stored in shared memory. One thing I am trying to monitor is the current req/sec and bytes/sec rate. On my test system I get about 3.5-4 Mbytes/sec (while testing with ab) which corresponds to the output in the mod_status page. But then suddenly the rate jumps to about 9 Mbytes/sec and I cannot explain it. I suspect it starts when the first generation of worker processes has reached MaxRequestsPerChild. Am I right that the worker_score members access_count and bytes_served are only increased over the whole lifetime of the server? Do they reflect the sum of requests and bytes served by any process using the slot? Initially I had simply added up those values from all worker_score entries. Then I took from mod_status this condition: if( ws-access_count!=0 || (ws-status!=SERVER_READY ws-status!=SERVER_DEAD) ) result[k].count+=ws-bytes_served; which doesn't seem to help much. Are there any conditions when a worker_score must not be counted? Thanks, Torsten
scoreboard.h/process_score question
Hi, the struct process_score in scoreboard.h contains a sb_type member. Can anyone please explain what that item is for? I couldn't find any usage in the code. The global_score does contain a similar member. That one is used. Thanks, Torsten
Re: MPMs, COW vs Child Process Spawning
On Wed 29 Oct 2008, Paul Querna wrote: Is COW ability of fork important enough with modern memory and operating systems, to maintain two significantly different code paths for spawning children processes? Don't know if it matters but mod_perl heavily relies on COW. Why drop a really valuable optimization? Torsten -- Need professional mod_perl support? Just hire me: [EMAIL PROTECTED]
Bug in ap_internal_fast_redirect
Hi dev, on the modperl mailing list we had recently an interesting problem that has revealed a bug in ap_internal_fast_redirect, see https://issues.apache.org/bugzilla/show_bug.cgi?id=45297 Suppose this config: DirectoryIndex index.shtml Options Includes Indexes AddType text/html .shtml AddOutputFilter INCLUDES .shtml Location /index.shtml Require valid-user AuthType basic AuthName Something very secret AuthUserFile /path/to/htpasswd /Location and an SSI document or an other handler that uses r-user as index.shtml: html body h1Hello !--#echo var=REMOTE_USER --/h1 /body /html If called directly as /index.shtml r-user is shown correctly. But if called via mod_dir as / the auth basic dialog appears but r-user is empty. The problem lies in ap_internal_fast_redirect. It simply forgets to copy r-user from the subrequest. I have attached a patch to the bug that solves the problem. But ... ap_internal_fast_redirect seems to me like an ugly hack. The name is very misleading. It pretends that an internal redirect is done but that's not true. The function simply copies values from a subrequest to the main request. It is called with 2 requests and one of them is a subreq and it practically overwrites the main req with the content of the subreq. In mod_dir the function is called from the fixup hook when it decides to use a certain document as DirectoryIndex. A subreq was previously used to check if the document exists as a regular file. So I am wondering wouldn't it be better to call ap_run_sub_req(subreq) to put out the response instead of that hack? I am trying to understand why ap_internal_fast_redirect is necessary at all? Thanks, Torsten
Re: Bug in ap_internal_fast_redirect
On Fri 27 Jun 2008, William A. Rowe, Jr. wrote: It's legacy crap that should be evicted from httpd-trunk, I'll do so sometime in July depending on vacations and such. You'll be able to review the patches to mod_dir and mod_negotiation and decide, should we actually push these into 2.2. That's good to hear. I didn't intend to remove ap_internal_fast_redirect from the 2.2 code. I only wanted to understand it. I suspect the code is really ancient. But please apply that little patch of mine to 2.2. Torsten -- Need professional mod_perl support? Just hire me: [EMAIL PROTECTED]
Re: Dynamic configuration for the hackathon?
On Tue 01 Apr 2008, Paul Querna wrote:
William A. Rowe, Jr. wrote:
-0.99 - agreed. Perl is perfectly happy having perl blocks as modular
behaviors... I've noticed a trend in the last few years of building on
the core (and folks rightfully accused me of growing mod_proxy core when
new directives are rightfully part of mod_proxy_{whatever}).
Yes, but the root of the problem even with perl blocks is that they
have almost no way to change the behavior of existing modules -- like
you can via configuration -- and instead for the most part, they
reimplment entire C modules in Perl, or any other language, rather than
binding to the configuration, and change that based on some other inputs.
I disagree. In the mod_perl API you can almost entirely configure a single
request. You can hook maptostorage and add there directives for other modules
via $r-add_config. Anything that can be configured in .htaccess or
Location can be done that way as well. One can even change DocumentRoot
(prefork-only) for a single request. The PerlMapToStorageHandler can then
decide whether to skip the standard maptostorage (directory walk and file
walk) or not. It would be good for such a perl-configured request to be able
to skip the location-walk that follows maptostorage. But if the admin wants
to do that he can simply avoid location blocks.
You cannot add virtual servers on the fly or redirect error_log. But I don't
expect that to become feasible in the new config language since those are
things that are done at server startup.
Then the existing configuration file, a new lua system, or anything
else, could be written in terms of that, rather than the current system
where each language reinvents the modules it wants to control.
I agree that a configuration language like lua is good but it doesn't
necessarily have to be in core. It can be a module as mod_perl shows.
Torsten
Re: Dynamic configuration for the hackathon?
On Tue 01 Apr 2008, Jim Jagielski wrote: On Apr 1, 2008, at 5:21 AM, Torsten Foertsch wrote: You cannot add virtual servers on the fly Hmmm let's see now. If we have a default Vhost that all non-matched name-based hosts get directed to configured, then a mod_perl based handler can be adjusted to look at the Server header and do different stuff based on what it's set to... envision a simple dynamic mapping. I know one can do that. But a VHost has a server_rec, maybe a separate error_log and access_log, etc. Those cannot be created at request time. That is what I meant. Torsten
Re: Dynamic configuration for the hackathon?
On Tue 01 Apr 2008, Akins, Brian wrote:
In pseudo config, like niq is suggesting, you could have something like:
If HTTP_HEADER{Host} =~ cnn\.com$ || TCPPort == 8080
#cnn specific stuff here...
DocumentRoot /htdocs/cnn
CutomLog |/usr/bin/logger cnn my_format
ErrorLog /var/log/cnn.error
/If
I don't like that. I think there are security considerations why logfiles are
opened from the parent process as root. But with other logging mechanisms
that provide write-only semantics it is good. In my setup the apache logs to
a named pipe to a process outside the chroot.
To really create vhosts on the fly I think a new hook in the MPM would be good
that is called from a configuration provider module. It reconfigures the
parent apache and does a graceful restart. This way almost anything can be
reconfigured. A question is whether the provider should send changes to the
apache or a complete new config. In the former case we'd need something like
UnListen localhost:80
CloseErrorLog ...
DeleteVirtualHost localhost:80
In the end the server_rec would go away. We have one server with a list of
loaded modules, a PidFile and an AcceptMutex that is listening on a list of
ports. The rest is configurable this way:
if localport==443 and localaddr=1.2.3.4
SSLCertificateFile ...
Protocol http # expecting HTTP to be spoken on the wire
if header_in{Host}=~cnn\.com
Timeout 10
ErrorLog ...
/if
/if
Or rather the request is passed to the config module that checks localport and
localaddr and issues the SSLCertificateFile directive. Then it checks the
Host-header ...
As for dynamic request configuration, I'd wish some configuration provider
with intelligent conftree caching. That provider then implements a language
as it likes, LUA, Perl, Apache-style if.../if, ... It generates a list of
directives that is compiled into a conftree.
As I understood it the main problem with the current mod_rewrite based config
is that it is too complex. The new language has to watch out not to end at
the same place. One thing that I think is messy is the use of subprocess_env
to pass information from module to module and even from administrator to
module: no-gzip, force-gzip, downgrade-1.0, nokeepalive, redirect-carefully
etc.
Torsten
Re: Dynamic configuration for the hackathon?
On Wed 26 Mar 2008, Akins, Brian wrote: There seems to be a demand for dynamic per-request configuration, as evidenced by the number of users hacking it with mod_rewrite, and the other very limited tools available. Modern mod_rewrite usage commonly looks like programming, but it's not designed as a programming language. Result: confused and frustrated users. This is what I had in mind when I suggested having Lua blocks of code. No need to invent a new language when a perfectly fine one exists... As Issac pointed out something similar can be done with Perl blocks at the cost of having mod_perl in core. Those are not evaluated evaluated per-request. But based on mod_perl there is Apache2::Translation that does per-request configuration. It hooks uri translation, maptostorage and fixup to do the job. Again it needs a perl interpreter in core and hence doesn't work well with threaded MPMs. So I was going to reimplement it based on mod_wombat some time this year. I just wanted to add these $0.02 to the discussion. Torsten
Re: [PATCH #21563] support/list_hooks.pl does not parse declarations that span multiple lines
On Tue 19 Feb 2008, Torsten Foertsch wrote: support/list_hooks.pl does not parse declarations that span multiple lines. The attached version does. See also bug #44453. Please take this mail as a polite reminder since nobody has answered this patch for almost a month now. I understand support/list_hooks.pl is not the most important part of httpd but it is included in the shipped package. So, why don't we make it work? Torsten list_hooks.pl Description: Perl program
[PATCH #21563] support/list_hooks.pl does not parse declarations that span multiple lines
Hi, support/list_hooks.pl does not parse declarations that span multiple lines. The attached version does. See also bug #44453. Torsten list_hooks.pl Description: Perl program
Re: High security
On Fri 25 Jan 2008, Nick Kew wrote: A compromise might be to create a chroot hook and allow module developers to use it. This would shift the support burden somewhat from the core Apache team to those willing to engage the users providing support. Isn't that basically the status quo (mod_security presumably hooks it in at post_config?) Sometimes I have missed a ChildPrivilegedInit hook that is run between fork() and dropping privileges in the worker. That would be the right place to chroot() I think. Torsten
how to get the request_rec if I have only the request pool?
Hi, if I have a pointer to a request pool is there then a simple way to fetch the corresponding request_rec? My current way is to put it there as pool userdata in a create request hook function. But I thought there might be a more sensible way. Thanks, Torsten pgpV3zBSSkkPb.pgp Description: PGP signature
Re: The right way to report problems (was: uninitialized variable in ap_directory_walk)
On Saturday 24 March 2007 13:53, Nick Kew wrote: Thanks for persisting! Thanks for applying the patch. I have marked the bug as fixed. Torsten pgpwL6wlBKRQa.pgp Description: PGP signature
Re: The right way to report problems (was: uninitialized variable in ap_directory_walk)
On Thursday 15 March 2007 20:25, Joshua Slive wrote: The bug is simple, the patch is simple. Why haven't I got a single reply to my mail? The bug is also still marked as new. What is the right way to report problems? You're doing fine. See: http://httpd.apache.org/dev/patches.html#ignored So, this is the next polite reminder. The bug has been introduced with revision 104283 of server/request.c which has been committed by pquerna. So, Paul, maybe you would be so kind and have a look at this one-line patch. See http://issues.apache.org/bugzilla/show_bug.cgi?id=41829 Thanks, Torsten pgpjEgb2xvalF.pgp Description: PGP signature
The right way to report problems (was: uninitialized variable in ap_directory_walk)
Hi, almost a week ago I have reported an uninitialized variable in server/request.c. I have also filed a bug (http://issues.apache.org/bugzilla/show_bug.cgi?id=41829). The bug is simple, the patch is simple. Why haven't I got a single reply to my mail? The bug is also still marked as new. What is the right way to report problems? But maybe I should explain the problem a bit. With mod_perl you can add configuration statements by $r-add_config(...). This can also be done in a maptostorage handler which comes handy because it allows you to set some initial values for AllowOverride or Options which are evaluated by the core maptostorage handler. So, with httpd 2.0.x this has worked without problem. With 2.2 the new override_opts were introduced. ap_directory_walk maintains its own copy of these flags along with the current override options in a structure named opts. The members of this structure are initialized from the requests per_dir_config. But somehow the new override_opts had been forgotten. By cause the override_opts member was in my installation always 0 thus preventing to set any other Options via .htaccess. Torsten On Sunday 11 March 2007 18:01, Torsten Foertsch wrote: this bug is alive since 2.2.0. The patch is against trunk. --- server/request.c~ 2007-03-11 17:20:25.0 +0100 +++ server/request.c2007-03-11 17:50:01.0 +0100 @@ -631,6 +631,7 @@ opts.add = this_dir-opts_add; opts.remove = this_dir-opts_remove; opts.override = this_dir-override; +opts.override_opts = this_dir-override_opts; /* Set aside path_info to merge back onto path_info later. * If r-filename is a directory, we must remerge the path_info, pgpggRohOAy25.pgp Description: PGP signature
uninitialized variable in ap_directory_walk
Hi, this bug is alive since 2.2.0. The patch is against trunk. Torsten --- server/request.c~ 2007-03-11 17:20:25.0 +0100 +++ server/request.c2007-03-11 17:50:01.0 +0100 @@ -631,6 +631,7 @@ opts.add = this_dir-opts_add; opts.remove = this_dir-opts_remove; opts.override = this_dir-override; +opts.override_opts = this_dir-override_opts; /* Set aside path_info to merge back onto path_info later. * If r-filename is a directory, we must remerge the path_info, pgpTbxsPEW5Tx.pgp Description: PGP signature
Re: [EMAIL PROTECTED] Re: how to modify Document Root from module...
On Monday 27 November 2006 00:57, Mathieu CARBONNEAUX wrote:
the idea is to fake document root after chrooting apache.
after reading configuration and setting document root, in child init i make
chroot to the actual document root, and after i whant to correct document
root to reflect the new document root /...
without that you must have document root that exist in chroot and outside
the chroot... because apache check if document root is directory at
configuration stage...
This is from mod_perl.
static apr_status_t restore_docroot(void *data)
{
struct mp_docroot_info *di = (struct mp_docroot_info *)data;
*di-docroot = di-original;
return APR_SUCCESS;
}
static MP_INLINE
const char *mpxs_Apache2__RequestRec_document_root(pTHX_ request_rec *r,
SV *new_root)
{
const char *retval = ap_document_root(r);
if (new_root) {
struct mp_docroot_info *di;
core_server_config *conf;
MP_CROAK_IF_THREADS_STARTED(setting $r-document_root);
conf = ap_get_module_config(r-server-module_config,
core_module);
di = apr_palloc(r-pool, sizeof *di);
di-docroot = conf-ap_document_root;
di-original = conf-ap_document_root;
apr_pool_cleanup_register(r-pool, di, restore_docroot,
restore_docroot);
conf-ap_document_root = apr_pstrdup(r-pool, SvPV_nolen(new_root));
}
return retval;
}
Torsten
pgpgc2Pz3XVqo.pgp
Description: PGP signature
Re: child_init hook...
On Friday 20 October 2006 22:40, Mathieu CARBONNEAUX wrote: i'm searching about to ameliorate chroot funciton of mod_chroot and mod_security module to be working normaly with apache reload. the probleme is that the chroot occure in apache main processes who control child forking... and not in the start of the child (after the fork)... because of that the chroot are permanante... and the apache main process canot be abel to reload configuration file that are outside of the chroot... my first idea is to make chroot in child_init hook in place of post_config... but...they dont work... and when have analysed the apache code have found why no working: the child_init hook occure after the setuid (unixd_setup_child) and after that is not possible to make chroot beceause at this point dont have the nessery right to do that... my question is how to make possible root action in child init phase? displacing the hook before unixd_setup_child ? but what is the impact of this ? adding a other hook placed before unixd_setup_child ? i'm interested of idea to resolve this! In the main apache: d=open(/, O_RDONLY); chroot(/new/root); At reload time: fchdir(d); chroot(.); do_reload(); chroot(/new/root); At child_init: close(d); Torsten pgphFifWHeSEA.pgp Description: PGP signature
Very simple patch
--- glue/perl/t/conf/extra.conf.in~ 2005-04-16 04:19:35.0 +0200
+++ glue/perl/t/conf/extra.conf.in 2006-01-18 21:20:34.020443622 +0100
@@ -1,3 +1,4 @@
+PassEnv PERL5LIB
ScriptAlias /cgi-bin/ @ServerRoot@/cgi-bin/
IfModule !mpm_winnt.c
LockFile @ServerRoot@/logs/accept.lock
Here is the problem is solves. If mod_perl is installed at a non-standard
location setting PERL5LIB is sufficient to make make test work for modperl
handlers but not for CGI scripts called by apache.
Some tests in glue/perl write CGI scripts that require APR::Pool co. Hence,
$ENV{PERL5LIB} must be passed through.
Torsten
pgpgiEA81MSWp.pgp
Description: PGP signature
APR: decision which shared mem implementation is used
Hi,
yesterday after a few experiments I found my apache won't start anymore. In the
error_log
it said:
[Tue Dec 13 12:09:46 2005] [crit] (17)File exists: unable to create scoreboard
/var/opt/apache/logs/apache_scoreboard (name-based shared memory failure)
Deleting /var/opt/apache/logs/apache_scoreboard didn't help. Strace then
revealed:
unlink(/var/opt/apache/logs/apache_scoreboard) = 0
open(/var/opt/apache/logs/apache_scoreboard, O_WRONLY|O_CREAT|O_EXCL, 0666) =
14
stat64(/var/opt/apache/logs/apache_scoreboard, {st_mode=S_IFREG|0644,
st_size=0, ...}) = 0
shmget(17191678, 225304, IPC_CREAT|IPC_EXCL|0600) = -1 EEXIST (File exists)
Well, obviously my apache uses SysV IPC for shared mem and my experiments left
over an
existing shm segment. First, I think, the error_log message is totally
misleading since
nothing is wrong with the file. Better would be something that says which
segment is to
be removed to start apache again.
Second, why is apache using SysV IPC on my linux box at all when mmap() is
available? Is
there a reason or just chance?
Configuring the APR that comes with 2.0.55 says it can use SysV IPC,
Classical mmap
or POSIX shm_open. On linux the last one is not really an option. The manpage
to shm_open
states:
The operation of shm_open is analogous to that of open(2). name speci‐
fies the shared memory object to be created or opened. For portable
use, name should have an initial slash (/) and contain no embedded
slashes.
Strace reveals that with shm_open apache want's to create
/dev/shm/var/opt/apache/logs/apache_scoreboard
as shared mem. That fails because the directory do not exists. Thus, on linux
the name
parameter to shm_open should not contain embedded slashes.
I think the configure process should check that.
But the mmap shared mem implementation works (by now) on my linux box:
unlink(/var/opt/apache/logs/apache_scoreboard) = -1 ENOENT (No such file or
directory)
open(/var/opt/apache/logs/apache_scoreboard, O_RDWR|O_CREAT|O_EXCL, 0666) = 14
ftruncate(14, 225312) = 0
lseek(14, 225312, SEEK_SET) = 225312
mmap2(NULL, 225312, PROT_READ|PROT_WRITE, MAP_SHARED, 14, 0) = 0x4063d000
close(14) = 0
I think this is better since it avoids hidden shared mem keys or ids.
Why APR configure chooses SysV IPC in the first place? configure.in looks like:
APR_BEGIN_DECISION([namebased memory allocation method])
APR_IFALLYES(header:sys/mman.h func:mmap func:munmap,
[havemmaptmp=1
APR_DECIDE(USE_SHMEM_MMAP_TMP,
[Classical mmap() on temporary file])])
APR_IFALLYES(header:sys/mman.h func:mmap func:munmap func:shm_open dnl
func:shm_unlink,
[havemmapshm=1
APR_DECIDE(USE_SHMEM_MMAP_SHM,
[mmap() via POSIX.1 shm_open() on temporary file])])
APR_IFALLYES(header:sys/ipc.h header:sys/shm.h header:sys/file.h dnl
func:shmget func:shmat func:shmdt func:shmctl,
[haveshmget=1
APR_DECIDE(USE_SHMEM_SHMGET, [SysV IPC shmget()])])
...
APR_END_DECISION
This explains it. SysV IPC wins because it is simply the last.
If what I said makes sense and there is no reason against Classical mmap then
maybe
the attached patch can be considered. It changes configure and configure.in.
I have also checked the APR that comes with 2.1.8. The decision process is the
same.
My box is suse linux 9.2 with linux 2.6.8 and glibc 2.3.3.
Torsten
--- httpd-2.0.55/srclib/apr/configure~ 2005-10-10 03:34:19.0 +0200
+++ httpd-2.0.55/srclib/apr/configure 2005-12-13 12:24:10.559527211 +0100
@@ -29272,7 +29272,7 @@
ac_decision=''
ac_rc=yes
-for ac_spec in header:sys/mman.h func:mmap func:munmap; do
+for ac_spec in header:sys/mman.h func:mmap func:munmap func:shm_open func:shm_unlink; do
ac_type=`echo $ac_spec | sed -e 's/:.*$//'`
ac_item=`echo $ac_spec | sed -e 's/^.*://'`
case $ac_type in
@@ -29297,11 +29297,11 @@
done
if test .$ac_rc = .yes; then
:
-havemmaptmp=1
- ac_decision='USE_SHMEM_MMAP_TMP'
-ac_decision_msg='Classical mmap() on temporary file'
-ac_decision_USE_SHMEM_MMAP_TMP=yes
-ac_decision_USE_SHMEM_MMAP_TMP_msg='Classical mmap() on temporary file'
+havemmapshm=1
+ ac_decision='USE_SHMEM_MMAP_SHM'
+ac_decision_msg='mmap() via POSIX.1 shm_open() on temporary file'
+ac_decision_USE_SHMEM_MMAP_SHM=yes
+ac_decision_USE_SHMEM_MMAP_SHM_msg='mmap() via POSIX.1 shm_open() on temporary file'
else
:
@@ -29309,7 +29309,7 @@
fi
ac_rc=yes
-for ac_spec in header:sys/mman.h func:mmap func:munmap func:shm_open func:shm_unlink; do
+for ac_spec in header:sys/ipc.h header:sys/shm.h header:sys/file.h func:shmget func:shmat func:shmdt func:shmctl; do
ac_type=`echo $ac_spec | sed -e 's/:.*$//'`
ac_item=`echo $ac_spec | sed -e 's/^.*://'`
case $ac_type in
@@ -29334,11
Re: Proposed connection state diagram
On Tuesday 06 September 2005 06:10, Brian Pane wrote: http://www.brianp.net/work/opensource/apache/async.html Shouldn't there be a transition from HANDLER to CHECK_REQUEST_LINE_READABLE in case the full response is sent and keep-alive is on? Torsten pgpGwArqwD7oI.pgp Description: PGP signature
Re: [PATCH] add TCP_DEFER_ACCEPT to 2.0.54
On Wednesday 04 May 2005 22:09, Brian Akins wrote: Compiles and works in initial testing on Linux 2.6 (debian sarge). I have tried that out and found that everything is working except testing mod_perl. The reason is simple and to be expected. One test (t/protocol/pseudo_http) implements a protocol module and is expecting to get something (the string HELO) from the server before sending any data. Maybe it is worth to make this option settable via httpd.conf? Torsten pgpB8EUp3hXMX.pgp Description: PGP signature
mod_ssl exported functions?
Hi, I am writing a mod_perl module that makes mod_ssl optional functions accessible via perl. I have currently implemented ssl_is_https() and ssl_var_lookup() which is enough for my needs. For the sake of completeness I am wondering if ssl_engine_disable() and ssl_proxy_enable() need to be interfaced. But I don't know what they are good for. Please give me a hint where to look. Thanks, Torsten pgp0BoWfy54HB.pgp Description: PGP signature
