Re: 2.2.11 mod_include

2009-04-01 Thread Dan Poirier
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).

-- 
Dan Poirier poir...@pobox.com



Re: 2.2.11 mod_include

2009-04-01 Thread Torsten Foertsch
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 at 

Re: 2.2.11 mod_include

2009-04-01 Thread Dan Poirier
Torsten Foertsch torsten.foert...@gmx.net writes:

 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.
...
 Should I attach these patches to the problem reports in bugzilla or is 
 that useless because they wont be backported officially?

 Torsten

These are two separate problems that just happen to have been fixed
recently in trunk.  I haven't looked at the rewrite one.

I don't know any reason why these couldn't be backported, but someone
with commit privileges will have to propose them for backporting.

Dan



2.2.11 mod_include

2009-03-31 Thread Torsten Foertsch
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


Re: 2.2.11 mod_include

2009-03-31 Thread Lars Eilebrecht
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


ciao...
-- 
Lars Eilebrecht
l...@eilebrecht.net