You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Justin Erenkrantz <je...@ebuilt.com> on 2001/10/16 03:52:47 UTC

mod_dir problems...

Okay, well, I have an idea what is causing the negotiation problems.
OtherBill probably has seen this, but I'll just make sure that I'm
seeing the same thing he is.

Consider this chunk of code from mod_dir.c (line 185):
        request_rec *rr = ap_sub_req_lookup_uri(name_ptr, r, NULL);

        if (rr->status == HTTP_OK && rr->finfo.filetype == APR_REG) {
            char *new_uri = ap_escape_uri(r->pool, rr->uri);

            if (rr->args != NULL)
                new_uri = apr_pstrcat(r->pool, new_uri, "?", rr->args,
NULL);
            else if (r->args != NULL)
                new_uri = apr_pstrcat(r->pool, new_uri, "?", r->args,
NULL);

            ap_destroy_sub_req(rr);
            ap_internal_redirect(new_uri, r);
            return OK;
        }

The key idea is that we are looking up index.html for a directory.
Consider the case where we have MultiViews enabled.  We run a
subreq for index.html, MultiViews hits (because index.html doesn't
exist) and decides to serve (say) index.html.en.  This subreq
seems to be generated from ap_sub_req_lookup_dirent which sets 
r->uri to "".  Since mod_dir wants to do the redirect via the
uri rather than the filename (which is the core of what mod_neg
has figured out), we end up going to "" which we treat as /.

Oops.  So, what to do?  Can we set r->filename to be rr->filename
(and relevant structs) and go from there?  Do we need a redirect
that keys off of filename (that seems silly since rr already has
all of the relevant info)?  We just need to force serving of
rr->filename.  (rr can't actually stand on its own because it lacks
a r->handler - mod_mime not executed on it?)  -- justin