httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Robert S. Thau)
Subject Re: index.html~ screwup
Date Thu, 15 Jun 1995 09:16:07 GMT
   Date: Wed, 14 Jun 1995 14:59:52 -0700 (PDT)
   From: Brian Behlendorf <>
   Precedence: bulk

   > This shouldn't matter because the function MultiViews uses to type files
   > (set_content_type_and_parms) does not, or should not, set the type of
   > otherwise unrecognized files to DefaultType, and MultiViews ignores files
   > which have no recognizable type assigned.  However, if any change to the
   > server changed that (e.g., if it gets changed by running the server with
   > the Arena bug workaround undone, which I've never done here), this would
   > be one of the expected symptoms...

   I'm still at 0.7.2h here.

OK, I think I see where the problem is coming from.  The function
which ultimately resolves content types file names is find_ct(); this
function sets request->content_type to pstrdup(default_type), where
default_type is one of its arguments.  When it's being called from
MultiViews, that argument is a null string (literally "" in the source
code), so request->content_type gets set to pstrdup("") --- a pointer
to one malloced '\0' byte.

However, the content-negotation code itself is checking for a null
*pointer*, when it determines whether or not to accept the file in
question as a possible variant, and that check can never succeed.  So,
if I'm right, changing the

        if (!request->content_type) continue;

in read_types_multi (in http_mime_db.c) to

        if (!request->content_type[0]) continue;

should solve the problem.


View raw message