Re: [PATCH] EVIL hack

[Dean Gaudet <dg...@arctic.org>]

On Tue, 27 Apr 1999, Raymond S Brand wrote:

> This message contains an EVIL hack. It is a patch that can be applied AFTER
> applying my patch to mod_autoindex.
> 
> >From my patch to mod_autoindex:
> > Quirks:
> > 	Some of the environment variables, as displayed by mod_include's #printenv, reflect
> > 	the header or readme file, not the directory. See the following "EVIL hack" message.
> 
> The following patch fixes the problem. It suffers from the following problems:
> 	1) mod_autoindex now requires mod_include.
> 	2) mod_include must be LoadModuled before mod_autoindex
> 	3) There REALLY needs to be a better way to do this so that
> 		independent modules do not become dependent on each
> 		other.

You know, to be honest, I'm thinking that mod_autoindex invoking
mod_include is the wrong way around.

If you were to add this to mod_autoindex:

static const handler_rec autoindex_handlers[] =
{
    {DIR_MAGIC_TYPE, handle_autoindex},
+   {"force-directory-index", handle_autoindex},
    {NULL}
};

And put a config directive such as:

AddHandler force-directory-index .force_index

Then <!--#include virtual="foo.force_index" -->

You should end up being able to invoke mod_autoindex from
mod_include... and solve both of the problems you've posted patches for.

I may have it slightly wrong -- I did produce a patch for this some time
ago, I forget what the reason for it was then.

Dean

Re: [PATCH] EVIL hack

[Raymond S Brand <rs...@rsbx.net>]

Dean Gaudet wrote:
> 
> You know, to be honest, I'm thinking that mod_autoindex invoking
> mod_include is the wrong way around.
> 
> If you were to add this to mod_autoindex:
> 
> static const handler_rec autoindex_handlers[] =
> {
>     {DIR_MAGIC_TYPE, handle_autoindex},
> +   {"force-directory-index", handle_autoindex},
>     {NULL}
> };
> 
> And put a config directive such as:
> 
> AddHandler force-directory-index .force_index
> 
> Then <!--#include virtual="foo.force_index" -->
> 
> You should end up being able to invoke mod_autoindex from
> mod_include... and solve both of the problems you've posted patches for.
> 
> I may have it slightly wrong -- I did produce a patch for this some time
> ago, I forget what the reason for it was then.
> 
> Dean

I've done more work on this and a lot of thinking too. The goal is to have
the ReadmeName and headerName files server parsed(*) and content negotiated(*)
as additions to the existing behavior of mod_autoindex. (*)If those
capabilities are loaded and enabled.(*) Having defined the goal, requiring
mod_include in order to deliver existing functionality is no good. (It's
also likely that nobody would be willing to commit that change.) Mod_inlcude
also has different file inclusion semantics than mod_autoindex.

My first patch achieves that goal, with one minor annoyance: the environment
variables in the included ReadmeName and headerName files reflect the
included files and not the directory. These is also some minor HTML code
generation cleanups too. I still think that patch should be committed.

That leaves fixing the environment variables. This is harder to do because
of how mod_include works.

The second patch, labeled "EVIL hack", was not intended to be committed but
to, hopefully, start a discussion on how to correct the environment variable
annoyance. And I was toasted, deservedly so by Ralf, for what the patch did.

I've also submitted a third patch; a replacement for "EVIL hack" the uses the
notes table in the request_rec to pass a flag to mod_include(*) to do the
env var fix ups. The patch as submitted is, unfortunately, incomplete, but the
full patch has been working fine for several days on my test setup. The only
difference is to NOT destroy the sub_reqs. I'll post the complete env var fix
patch shortly.

Raymond S Brand