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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
