Mailing List Archive

On Wed, 14 Jun 1995, Robert S. Thau wrote:
> Could you check if what it's serving in the calendar directory is actually
> the ~ file? If so, it could be a MultiViews screwup --- the order of the
> files in the two directories (i.e., the physical order in which readdir()
> would read them out) is different.

Yes, it's serving out the index.html~.

> 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.

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/

Date: Wed, 14 Jun 1995 14:59:52 -0700 (PDT)
From: Brian Behlendorf <brian@organic.com>
Cc: new-httpd@hyperreal.com
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

> 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.

rst

On Thu, 15 Jun 1995, Robert S. Thau wrote:
> 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.

No, it made the server completely unresponsive... nothing was getting
served (except for a few 302's and 404's).

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/

Sigh... I guess I'll have to try debugging this myself on hyperreal tmrw.

rst