From: "Marc Slemko" <[EMAIL PROTECTED]>
> On Sun, 19 Aug 2001, Lars Eilebrecht wrote:
>
> > > > Another entry for the todo list:
> > > >
> > > > - Add the config for this to httpd-std.conf. I believe
> > > > that we should enable it by default.
> > >
> > > Not just yet ... let's get the language issues straightened out. Also, it
> > > loads down the server, dunno if we want to do that to administrators :)
> >
> > We already activate MultiViews by default, so I don't think this is
> > a problem.
>
> Well, that assumes two things.
>
> Assumption 1: Having multiviews on by default the way things are now is
> "ok". I'm not really thrilled with it, and haven't been since it was
> done... it has already introduced a variety of security and functionality
> issues, and is likely to continue to do so because it enables a new code
> path that is complex in concept and somewhat convoluted in implementation.
I believe this can be solved. I don't believe it can be solved to everyone's
complete satisfaction, but let me offer some ideas.
1. Leave global Multiview configuration stuff in httpd.conf, but not enabled for '/'.
2. Enable Multiviews in /manual/ to resolve that section. If the user fails to update
their global configuration, -so-be-it-. The bugfix that ignores unrecognize .exts
will simply leave some_docs.html.new un-negotiatable if they haven't added .new.
Set the ForceDefaultLanguages for that section so we serve -something-.
3. Create an /index.html.var typemap of _all_ the /index.html.foo variants in our
default htdocs. Updating the docs/docroot/ files will clean up the entire list.
This must be maintained as we add new documents to that collection. If the user
installs just the htdocs/ directory, their 'mappings' will be updated in the
process.
4. Change the default document list to serve index.html index.html.var in that order.
This will shortcut a ton of time negotating the content by stat() calls, since
without Multiviews we won't look for index.html.*, but we will catch the typemap :)
Could this solution presuade everybody between 0 and +1 for negotated content?
> Assumption 2: This doesn't introduce any issues beyond what the
> multilingual index.html files do. I'm not sure that is valid. The
> reality is that the vast majority of Apache users do NOT use language
> negotiation to make multiple languages available. Having localized error
> pages on a non-localized site simply isn't all that useful just like,
> IMHO, having localized default index.html pages in languages where there
> is nothing else available in that language isn't all that useful. The
> typical user will get rid of the default index files when they add their
> own content (which means there is no longer any point in having multiviews
> enabled on that server to begin with, although most will unfortunately not
> disable it), but having error pages internationalized by default is
> different because they may stick around for an extended period. Error
> pages are also often shown in... well... error conditions, and the
> overhead of having a large number of varients could get to be quite
> significant if there is a high traffic volume.
I need to think about this whole problem before I have any concrete ideas. Once little
solution, though, might be to actually allow _content_ within a typemap file, such that
no subrequest is run. That means every error 'code' file would become effectively
a single mapping list with dozens of little content 'bits'.
Does that appeal?
> I'm not trying to discourage internationalization of docs or the
> work people have done, but think we have to be careful to keep
> things in perspective and not loose sight of what users actually
> want and need... I strongly believe that a well thought out yet fairly
> minimal and conservative in ways that make sense default configuration is
> what we want.
It's significantly
