Mailing List Archive

XBITHACK works on *all* files in the base code (if it has the XBIT on, and
it isn't a CGI script, it gets full includes processing). There may be
people relying on this. It should *certainly* be on for at least all of
text/* (your patch would disallow it for html3 files; also, it core dumps
if no content type was identified from suffix, and r->content_type is NULL;
it should check the default_type in that case if we want to do this at all,
which I doubt).

*** mod_include.c.orig Fri Sep 22 09:50:43 1995
--- mod_include.c Fri Sep 22 10:02:07 1995
***************
*** 838,843 ****
--- 838,846 ----
&includes_module);

if (*state == xbithack_off) return DECLINED;
+
+ if (strcmp(r->content_type, "text/html")) return DECLINED;
+
return send_parsed_file (r);
}

> XBITHACK works on *all* files in the base code (if it has the XBIT on, and
> it isn't a CGI script, it gets full includes processing). There may be
> people relying on this. It should *certainly* be on for at least all of
> text/* (your patch would disallow it for html3 files; also, it core dumps
> if no content type was identified from suffix, and r->content_type is NULL;

mmm, nice :-)

I'll work on a new patch.

> it should check the default_type in that case if we want to do this at all,
> which I doubt).

I think it needs to be done. I'd expect it to save a lot of misery.

I dealt with someone with this problem yesterday. By the end of the day
he was cursing Apache and talking about CERN. It's a difficult problem
to track down, especially via email. What compounds the problem is
that Netscape displays the gif/jpeg inlines even when they are sent as
text/html (after being accidentally parsed).


rob

rst wrote,

> text/* (your patch would disallow it for html3 files; also,

does these mean that it will currently parse a file with type
say text/html3 but then proceed to stamp it as text/html ?

-=-=-=-=

int send_parsed_file(request_rec *r)

stamps the type as "text/html" - which was the cause of the problem with
+x images being parsed.

Do we need to determine the type based on mime.types and AddType but
exclude "x-server-parsed" at this stage.

So if by some accident we end up parsing a gif, the .gif extension
should force an image/gif type to be send to the client.

-=-=-=-=-=

Alternatively and/or additionally, do we need a option,

AddType text/x-xbithack-server-parsed-html

so that people can restrict xbithack to a subset of the +x'ed files e.g.

AddType text/x-xbithack-server-parsed-html html


rob