This patch is wrong. Only text/html output is valid for consideration.
Just because no handler has been associated to the handler doesn't mean
we should blindly accept the file. Contrawise, even another handler
(e.g. PHP) could be xbithacked using the new filtering features.
So perhaps this is a better test;
if (!r->content_type || strcmp(r->content_type, "text/html")) {
return DECLINED;
}
However, I'm of a mind that we should perhaps allow any text/* types that
the administrator is interested in to be considered for xbit testing.
That would include things like xml content, etc. What about changing the
xbithack enable to something like
XBitHackByType text/html text/xml text/application-xml
or some such? This array could be skimmed in place of this test, and the
absense of a match would decline include's xbit-toggled participation
in serving the request.
Just a thought.
Bill
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, December 29, 2001 3:34 PM
Subject: cvs commit: httpd-2.0/modules/filters mod_include.c
> brianp 01/12/29 13:34:04
>
> Modified: modules/filters mod_include.c
> Log:
> Fix to make xbithack work again
>
> Revision Changes Path
> 1.175 +1 -1 httpd-2.0/modules/filters/mod_include.c
>
> Index: mod_include.c
> ===================================================================
> RCS file: /home/cvs/httpd-2.0/modules/filters/mod_include.c,v
> retrieving revision 1.174
> retrieving revision 1.175
> diff -u -r1.174 -r1.175
> --- mod_include.c 28 Dec 2001 17:44:28 -0000 1.174
> +++ mod_include.c 29 Dec 2001 21:34:04 -0000 1.175
> @@ -3220,7 +3220,7 @@
> return DECLINED;
> }
>
> - if (!r->handler || strcmp(r->handler, "text/html")) {
> + if (r->handler && strcmp(r->handler, "text/html")) {
> return DECLINED;
> }
> }
>
>
>
>
