William A. Rowe, Jr. wrote:
>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;
> }
>
That looks good; I'll change the code to check content_type
instead of handler.
>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
>
-0. I think xbithack in general is a bad thing (because it relies
on a subtle misuse of filesystem metadata to control web server
behavior), so I'm not strongly in favor of enhancing it...but I
won't stand in the way of anyone who is. :-)
--Brian
