You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2001/12/02 11:14:51 UTC

[patch] mod_dir refactored... needs discussion

Looking deeply into the issues of redirection, it really struck me
some time ago, why do we abuse the schema with ap_internal_fast_redirect()?

I've gotten used to the idea of mod_negotation calling that function, it
was just recently fixed (_redirect, not negotiation.)  The error in multiviews
is that the subrequest doesn't include the path_info and uri up front, in order
to [entirely] correctly process the language-specific request.  [You can't
just 'tack it on' - this patch to mod_dir illustrates the right approach.]
Now I begin to wonder, if we created a fast_redirect method for mod_negotation, 
why on earth shouldn't mod_dir follow the same convention?

Here's a patch - heavily refactored.  It merits discussion.  I expect it 
could break things, but I postponed it outside of the type_checker phase just 
to ensure that other fixups got first crack at alternative presentations.

Comments?

Bill




Re: [patch] mod_dir refactored... needs discussion

Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "William A. Rowe, Jr." <wr...@rowe-clan.net>
Sent: Sunday, December 02, 2001 4:14 AM


> Now I begin to wonder, if we created a fast_redirect method for mod_negotation, 
> why on earth shouldn't mod_dir follow the same convention?
> 
> Here's a patch - heavily refactored.  It merits discussion.  I expect it 
> could break things, but I postponed it outside of the type_checker phase just 
> to ensure that other fixups got first crack at alternative presentations.

Just so you know, the immediate effect is on mod_autoindex - which now believes
[rightly or wrongly] that this is the 'page' not the 'directory', since the
fixup happens within the request processing.  Something would need to be done
about that, I'm open to suggestions.

Bill


Re: [patch (rev 2)] mod_dir refactored... needs discussion

Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "William A. Rowe, Jr." <wr...@covalent.net>
Sent: Sunday, December 02, 2001 9:31 PM


> From: "William A. Rowe, Jr." <wr...@rowe-clan.net>
> Sent: Sunday, December 02, 2001 4:14 AM
> 
> 
> > Now I begin to wonder, if we created a fast_redirect method for mod_negotation, 
> > why on earth shouldn't mod_dir follow the same convention?
> 
> 
> Following this little experiment one step further, I've come to some conclusions;

Forgot to mention

3. It's more robust.  Currently, /test/ is confirmed as a valid address [not an error
   or other problem.]  With this patch, if /test/index.html is denied, the user won't
   be shown /test/ (which is a good thing, IMHO.)

But reflecting on the patch, perhaps we should allow the admin to configure Autoindex
to 'drill' into DIRs, or to always serve all (non-excluded) DIR entries without any
subrequest checking whatsoever.  Same on content, I suppose, although it would break
all of the ByType directives for directories configured that way.

Bill


Re: [patch (rev 2)] mod_dir refactored... needs discussion

Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "William A. Rowe, Jr." <wr...@rowe-clan.net>
Sent: Sunday, December 02, 2001 4:14 AM


> Now I begin to wonder, if we created a fast_redirect method for mod_negotation, 
> why on earth shouldn't mod_dir follow the same convention?


Following this little experiment one step further, I've come to some conclusions;

1. It's nicer.  That is, if you set up a subrequest to /webfiles/index.html.en,
   and look at its headers, you discover it's text/html, and in english.  If you
   execute the subrequest, you serve text/html english sub-content.

   If you set up a subrequest to /webfiles/, although it _will_ serve content, you
   don't know ahead of time that it happens to be english, in text/html.  If you
   execute the subrequest, you ACTUALLY serve text/html english sub-content.  So
   checking rr-> after a lookup doesn't do much for trust, does it?

2. It would be confusing to modules checking if /foo/ is a directory.  Well gee
   guys, it ends in a slash, must be a directory ;)

So, taking this all to it's logical conclusion, I've refactored a bit of the
autoindex code to do something equally useful - show DIRs as DIRs, in spite of
the mod_dir change.

I see two immediate opportunities to further improve mod_autoindex, but I don't
have the time to devote, I need to close the mod_negotation side of these issues.

a. A Really Cool feature would show Redirect entries [things in the directory that
   would return an _EXTERNAL_ redirect] as an LNK (pointy finger and all.)  But
   more important to Apache, the href="" would contain the redirect RESULT :)
   Now that saves a roundtrip to resolve something that we already could have
   shared with the client.

b. This patch isn't ready to close since it doesn't address APR_LNK files.  We
   need to decide if this points at an APR_DIR in the first place, before all the
   rest of the redirections.  No good suggestion at this moment.

That's all I had to share, comments, anyone?

Bill