You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Marc Slemko <ma...@znep.com> on 2001/08/19 20:24:19 UTC
Re: Multi Language Error Documents
(cced to new-httpd, since this really impacts a lot more than just the
docs and I think a whole lot of people are not on the docs mailing
list...)
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.
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'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.
Re: Multi Language Error Documents
Posted by Martin Kraemer <Ma...@Fujitsu-Siemens.com>.
On Sun, Aug 19, 2001 at 02:44:31PM -0500, William A. Rowe, Jr. wrote:
>
> 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?
+1. Yes, that would reduce the file system access to three open()s
(1 failed for index.html, 1 successful for index.html.var, 1 for the
actual index.html.<lang>) from a complete directory search.
> I need to think about this whole problem before I have any concrete ideas. One 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?
It reminds me of mod_include's functionality. We could add a new XSSI
directive <!--#switch val="$HTTP_ACCEPT_LANGUAGE" --> and
<!--#case expr="(en|en-us)" --> ----- uh oh. No, I agree with everyone who
read this far -- mod_include was not intended for programming. And
the actual negotiation algorithm would be lost. So: "enhancing" mod_include
is not the way to go.
Martin
--
<Ma...@Fujitsu-Siemens.com> | Fujitsu Siemens
<ma...@apache.org> | 81730 Munich, Germany
Re: Multi Language Error Documents
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Martin Kraemer" <Ma...@Fujitsu-Siemens.com>
Sent: Monday, August 20, 2001 2:44 AM
> On Sun, Aug 19, 2001 at 11:10:15PM -0500, William A. Rowe, Jr. wrote:
> > By using a Type Map with integrated content (one file per error) - see my commit tommorow :)
>
> Side Proposal: Use a MIME format with multipart/alternative, add a
> MIME parser to Apache, and use the MIME headers to select the correct
> variant.
Very similar to what I did, and I'm not altogether happy about my syntax.
It requires some sort of tags, because the body may contain binary data
(think in terms of a collection of gifs, or including some very obscure
encodings.) I added the body tag to include (as binary) everything to
the end tag. This patch was simply the straightest line.
The patch is attached. It has an intrinsic limit of 8100 some bytes per
body, which isn't that unreasonable, but could be expanded. Longer entities
should be dropped into their own URI: locations. It creates file buckets, and
just caches the offsets, rather than reading in all the possible bodies before
we run the negotation. File buckets are pretty slick :)
I've attached the auth_required.html.var messages from Lars' collection. I added
the images and include folders to /serverroot/error/ and placed this file in this
folder, added the following;
Alias /error/ "/serverroot/error/"
<Directory "/serverroot/error">
AllowOverride None
Options IncludesNoExec
AddHandler type-map var
SetOutputFilter Includes
Order allow,deny
Allow from all
</Directory>
# we're going nowhere fast :)
Alias /secure/ "/serverroot/secure/"
<Directory "/serverroot/secure">
AllowOverride None
Options Multiviews
Order allow,deny
Allow from all
AuthUserFile "/serverroot/conf/.htsecure"
AuthName "why?"
AuthType basic
Require valid-user
</Directory>
Experiment, and please comment on my (admittedly lame) syntax.
Bill
Re: Multi Language Error Documents
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Martin Kraemer" <Ma...@Fujitsu-Siemens.com>
Sent: Monday, August 20, 2001 2:44 AM
> On Sun, Aug 19, 2001 at 11:10:15PM -0500, William A. Rowe, Jr. wrote:
> > By using a Type Map with integrated content (one file per error) - see my commit tommorow :)
>
> Side Proposal: Use a MIME format with multipart/alternative, add a
> MIME parser to Apache, and use the MIME headers to select the correct
> variant.
To answer your proposal (and I suggest retaining my own once we fix the syntax
to everyone's satisfaction) ...
We should do either what you suggest, or create an XML database (easily split
by expat) as an alternate typemap syntax.
Basically, mod_negotiation is too big right now. We need to split it into these
groups of behavior;
A handler that constructs an internal typemap from our RFC822 typemap syntax,
passes it to a common internal typemap negotiator, and does the redirect or
serves the content.
A handler that implements multiviews by constructing an internal typemap from
a readdir() pattern matching function, passes it to the internal typemap
negotiator, and does the redirect.
A future handler that parses XML.
A future handler that parses multipart/alternative.
The Negotiator that takes an internal typemap, the client's headers, and returns
a 'best fit'. The negotiator is going to someday need to add 'translation' that
text/plain can be upgraded to text/html by an output filter, or one charset
is easily converted to another by a charset filter. Quality becomes a big issue,
converting any to utf-8 is almost always q=1.0, but going from utf-8 to a local
page is more like q=.001 due to mapping errors :( Text/plain to text/html is down
at a quality of .001 because it's formatting is far less than the real text/html
file would offer.
I think we aught to start using our conftree stuff for this, but I'm not touching
that issue today.
I'll commit my Body: parsing code unless I see a -1 this morning, and we can fix the
syntax in-tree after it's committed, if someone has a specific, good suggestion.
Bill
Re: Multi Language Error Documents
Posted by Martin Kraemer <Ma...@Fujitsu-Siemens.com>.
On Sun, Aug 19, 2001 at 11:10:15PM -0500, William A. Rowe, Jr. wrote:
> By using a Type Map with integrated content (one file per error) - see my commit tommorow :)
Side Proposal: Use a MIME format with multipart/alternative, add a
MIME parser to Apache, and use the MIME headers to select the correct
variant.
Martin
--
<Ma...@Fujitsu-Siemens.com> | Fujitsu Siemens
<ma...@apache.org> | 81730 Munich, Germany
Re: Multi Language Error Documents
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Martin Kraemer" <Ma...@Fujitsu-Siemens.com>
Sent: Monday, August 20, 2001 2:41 AM
> On Sun, Aug 19, 2001 at 11:10:15PM -0500, William A. Rowe, Jr. wrote:
> > What I committed was the most -optimal- solution, not necessarily the more predictable
> > one. I think we should change the docco to tell the user to edit the docroot (and
> > assign it's permissions) rather than encouraging them to change the contents of our
> > distribution htdocs directory. But that's just my 2c.
>
> Why do we use the double-typed
> index.html.var
> at all? Wouldn't it be more predictable to use
> DirecoryIndex index.var index.html index
> and put the index.html.<lang> files into the index.var file?
Good Q ... because a user that defined 'index.html' as their hyperlink to a directory,
and turned on multiviews, _still_ gets index.html.var.
And index.html.var will the authoritative list of langagues and charsets for our docroot
index.html.foo collection.
One big problem in the past, we have a bunch of folks that updated that list of docs,
but never brought httpd.conf up-to-date. Other bugs either 1. served the wrong (.tw) file
because of its size, or 2. escaped out of negotation into autoindex. The bugs are gone,
but it wouldn't have happened if they carry the typemap along with the index files.
> That would avoid the ambiguity between index.html.<lang> and
> index.html.var. In the absence of an index.var, the user's index.html
> (possibly even index.html.<lang> by way of MultiViews) would be found
> as usual.
I believe we are all saying index.html, then index.html.var, so a new index.html file
will be caught.
Bill
Re: Multi Language Error Documents
Posted by Martin Kraemer <Ma...@Fujitsu-Siemens.com>.
On Sun, Aug 19, 2001 at 11:10:15PM -0500, William A. Rowe, Jr. wrote:
> What I committed was the most -optimal- solution, not necessarily the more predictable
> one. I think we should change the docco to tell the user to edit the docroot (and
> assign it's permissions) rather than encouraging them to change the contents of our
> distribution htdocs directory. But that's just my 2c.
Why do we use the double-typed
index.html.var
at all? Wouldn't it be more predictable to use
DirecoryIndex index.var index.html index
and put the index.html.<lang> files into the index.var file?
That would avoid the ambiguity between index.html.<lang> and
index.html.var. In the absence of an index.var, the user's index.html
(possibly even index.html.<lang> by way of MultiViews) would be found
as usual.
Martin
--
<Ma...@Fujitsu-Siemens.com> | Fujitsu Siemens
<ma...@apache.org> | 81730 Munich, Germany
Re: Multi Language Error Documents
Posted by Marc Slemko <ma...@znep.com>.
On Mon, 20 Aug 2001, Martin Kraemer wrote:
> > 1. set DirectoryIndex index.html index.html.var
>
> Still, wouldn't index.var cause less confusion?
The "common use" of filenames is a basename and one extension. People can
have things like index.html and index.jsp in the same directory; in fact,
some people (foolishly) setup an index.html with a meta refresh to a
index.jsp. In other cases, there can be more legitimate reasons to have
the same basename with different extensions. Not including the .html (or,
by extension, whatever other extentions on other files they are trying to
vary on) adds ambiguity. index.html.var says we are varying among
index.html.*. index.var only says we are varying among index.*, which
isn't as precise.
There is a bit of possible namespace overlap both ways, but I don't see
taking "var" away from the list of available language abbreviations as a
big deal...
Re: Multi Language Error Documents
Posted by Martin Kraemer <Ma...@Fujitsu-Siemens.com>.
On Mon, Aug 20, 2001 at 01:30:28AM -0700, Marc Slemko wrote:
> But that's my whole point of wanting the config setup this way...
Yep, agreed. I misunderstood what you meant by "default page".
> 1. set DirectoryIndex index.html index.html.var
Still, wouldn't index.var cause less confusion?
Martin
--
<Ma...@Fujitsu-Siemens.com> | Fujitsu Siemens
<ma...@apache.org> | 81730 Munich, Germany
Re: Multi Language Error Documents
Posted by Marc Slemko <ma...@znep.com>.
On Mon, 20 Aug 2001, Martin Kraemer wrote:
> On Mon, Aug 20, 2001 at 12:51:07AM -0700, Marc Slemko wrote:
> > huh? Are you trying to say that performance is the number one criteria
> > for the default "Test Page for Apache Installation" index page?
> >
> > I'm not sure i follow...
>
> Okay, if you see it this way. I have had quite a lot of customers
> who copied the default configuration with very little change.
> And usually, "their" /index.html's performance IS a concern to them.
But that's my whole point of wanting the config setup this way...
1. set DirectoryIndex index.html index.html.var
2. the default documentroot has no index.html, so it passes over
it to index.html.var. There is a slight performance hit here for
the default index page due to the negotiation.
3. user adds their own index.html. The server uses it, no performance
hit at all from any negotiation stuff, regardless of if they get
rid of all the default index.html.* stuff or not.
The performance in #2 is irrelevant and has nothing to do with the
performance in #3.
Re: Multi Language Error Documents
Posted by Martin Kraemer <Ma...@Fujitsu-Siemens.com>.
On Mon, Aug 20, 2001 at 12:51:07AM -0700, Marc Slemko wrote:
> huh? Are you trying to say that performance is the number one criteria
> for the default "Test Page for Apache Installation" index page?
>
> I'm not sure i follow...
Okay, if you see it this way. I have had quite a lot of customers
who copied the default configuration with very little change.
And usually, "their" /index.html's performance IS a concern to them.
If it's suboptimal, they'll blame it on us. We need at least to write
something into the config file how to get best performance for the
server's /index.html (and/or how to get best multi-lang flexibility
at the cost of performance).
Martin
--
<Ma...@Fujitsu-Siemens.com> | Fujitsu Siemens
<ma...@apache.org> | 81730 Munich, Germany
Re: Multi Language Error Documents
Posted by Marc Slemko <ma...@znep.com>.
On Mon, 20 Aug 2001, Martin Kraemer wrote:
> On Sun, Aug 19, 2001 at 09:40:17PM -0700, Marc Slemko wrote:
> > But again, that's
> > ok, since performance is not the number one criteria for the default
> > index page.
>
> I wonder if the zillions of Apache users agree with THAT claim...
huh? Are you trying to say that performance is the number one criteria
for the default "Test Page for Apache Installation" index page?
I'm not sure i follow...
Re: Multi Language Error Documents
Posted by Martin Kraemer <Ma...@Fujitsu-Siemens.com>.
On Sun, Aug 19, 2001 at 09:40:17PM -0700, Marc Slemko wrote:
> But again, that's
> ok, since performance is not the number one criteria for the default
> index page.
I wonder if the zillions of Apache users agree with THAT claim...
Martin
--
<Ma...@Fujitsu-Siemens.com> | Fujitsu Siemens
<ma...@apache.org> | 81730 Munich, Germany
Re: Multi Language Error Documents
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Marc Slemko" <ma...@znep.com>
Sent: Sunday, August 19, 2001 11:40 PM
> On Sun, 19 Aug 2001, William A. Rowe, Jr. wrote:
>
> > When I proposed it, I blew it. I agree it might be 'unexpected' unless we document
> > it well, but we have a basic problem. If we go index.html -> index.html.var, we get
> > an extra stat. Worse, we may (if they've toggle multiviews themselves) end up walking
> > the multiview search, and then finding the .var which toggles it's own negotation.
>
> Neither of those matter though. An extra stat() in the default
> configuration when hitting the default page, that will almost
> certainly go away when content is put up by the user, is irrelevant.
Ok... if we can find index.html, I suppose that we serve it over index.html.var
in htdocs. Feel free to commit a patch :)
> Look at it this way: if you have .html.var then .html, every other
> request is going to have an extra stat(). Which is more common: a .var
> file being there, or a .var file not being there?
Agreed :)
> If they enable multiviews... well, then we just have to trust what they
> are doing.
I don't, but this is a 'play' site anyways.
> I just think that the reality is users will take the default install,
> and start adding their content. So the configuration should be
> tuned around that.
Fair enough. I'd still like to 'recommend' they create their own web tree and point our
htdocs to that directory. I believe the /manual alias helps them do that.
> > > So I like the idea of using a type map so multiviews don't have to be
> > > enabled for "/". The performance for / requests will still be
> >
> > ??? pretty fast. We have another issue. We need to stop stat'ing to get file sizes.
>
> It is pretty fast, but nowhere near fast as serving non-negotiated
> static content will be once the code path is optimized. But it is
> "fast enough", since performance only matters in certain contexts.
Just remember. The average 'joe user' who is doing a benchmark just compares;
http://www.server.com/
and sees what happens when they toggle servers :)
> > It's bogus. Heck, SSI and CGI are generally 'smaller' than precomposed pages. But
> > I sure don't think they save us a thing. Testing the size wastes more cpu than just
> > serving our first best match. Once that is done, this should be _very_ optimal.
>
> You still have to open and parse an extra file and take a fair hit
> due to decreased locality of reference, etc. But again, that's
> ok, since performance is not the number one criteria for the default
> index page.
Want to bet :-? I still argue that "Size Doesn't Matter" :) Not in negotated content
at least. I say draw straws.
Bill
Re: Multi Language Error Documents
Posted by Marc Slemko <ma...@znep.com>.
On Sun, 19 Aug 2001, William A. Rowe, Jr. wrote:
> From: "Marc Slemko" <ma...@znep.com>
> Sent: Sunday, August 19, 2001 9:23 PM
>
>
> > On Sun, 19 Aug 2001, William A. Rowe, Jr. wrote:
> >
> > > 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 :)
> >
> > Note that this doesn't work when people do silly things like use
> > "/index.html" instead of "/". Typically many people creating content use
> > the two interchangeably. But that's ok, I think... since random people
> > shouldn't be making documents linking to the default index page.
> > Although we should perhaps make sure there are no silly links in the docs
> > that reference /index.html.
> >
> > Hrm. When you committed the DirectoryIndex change, you did .html.var
> > first then .html. Shouldn't it be the other way around (like you stated
> > above)? In the current order, if someone sticks there own index.html in
> > there, it will not behave entirely as expected in odd (to the user)
> > ways...
>
> When I proposed it, I blew it. I agree it might be 'unexpected' unless we document
> it well, but we have a basic problem. If we go index.html -> index.html.var, we get
> an extra stat. Worse, we may (if they've toggle multiviews themselves) end up walking
> the multiview search, and then finding the .var which toggles it's own negotation.
Neither of those matter though. An extra stat() in the default
configuration when hitting the default page, that will almost
certainly go away when content is put up by the user, is irrelevant.
Look at it this way: if you have .html.var then .html, every other
request is going to have an extra stat(). Which is more common: a .var
file being there, or a .var file not being there?
If they enable multiviews... well, then we just have to trust what they
are doing.
I just think that the reality is users will take the default install,
and start adding their content. So the configuration should be
tuned around that.
> > So I like the idea of using a type map so multiviews don't have to be
> > enabled for "/". The performance for / requests will still be
>
> ??? pretty fast. We have another issue. We need to stop stat'ing to get file sizes.
It is pretty fast, but nowhere near fast as serving non-negotiated
static content will be once the code path is optimized. But it is
"fast enough", since performance only matters in certain contexts.
> It's bogus. Heck, SSI and CGI are generally 'smaller' than precomposed pages. But
> I sure don't think they save us a thing. Testing the size wastes more cpu than just
> serving our first best match. Once that is done, this should be _very_ optimal.
You still have to open and parse an extra file and take a fair hit
due to decreased locality of reference, etc. But again, that's
ok, since performance is not the number one criteria for the default
index page.
Re: Multi Language Error Documents
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Marc Slemko" <ma...@znep.com>
Sent: Sunday, August 19, 2001 9:23 PM
> On Sun, 19 Aug 2001, William A. Rowe, Jr. wrote:
>
> > 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 :)
>
> Note that this doesn't work when people do silly things like use
> "/index.html" instead of "/". Typically many people creating content use
> the two interchangeably. But that's ok, I think... since random people
> shouldn't be making documents linking to the default index page.
> Although we should perhaps make sure there are no silly links in the docs
> that reference /index.html.
>
> Hrm. When you committed the DirectoryIndex change, you did .html.var
> first then .html. Shouldn't it be the other way around (like you stated
> above)? In the current order, if someone sticks there own index.html in
> there, it will not behave entirely as expected in odd (to the user)
> ways...
When I proposed it, I blew it. I agree it might be 'unexpected' unless we document
it well, but we have a basic problem. If we go index.html -> index.html.var, we get
an extra stat. Worse, we may (if they've toggle multiviews themselves) end up walking
the multiview search, and then finding the .var which toggles it's own negotation.
What I committed was the most -optimal- solution, not necessarily the more predictable
one. I think we should change the docco to tell the user to edit the docroot (and
assign it's permissions) rather than encouraging them to change the contents of our
distribution htdocs directory. But that's just my 2c.
> So I like the idea of using a type map so multiviews don't have to be
> enabled for "/". The performance for / requests will still be
??? pretty fast. We have another issue. We need to stop stat'ing to get file sizes.
It's bogus. Heck, SSI and CGI are generally 'smaller' than precomposed pages. But
I sure don't think they save us a thing. Testing the size wastes more cpu than just
serving our first best match. Once that is done, this should be _very_ optimal.
Can everyone else agree we aught to drop the size test? Simply drop in a '1' for the
size of any typemap-negotatied resource?
> Leaving multiviews enabled for the docs subtree is ok from a performance
> and random bugs standpoint... there are still possibilities for security
> issues, but they should be minimal.
Not if I did my job with the last patches :) OTOH, I really agree with your comment
about testing. I believe that we should enable as many features as possible, in
different (appropriate) places, so we, and the user, has a chance to uncover as many
bugs as possible durring this alpha/beta testing phase.
> But... we still have the original question of the multi-lingual error
> messages, and if they should be enabled by default and, if so, then how.
By using a Type Map with integrated content (one file per error) - see my commit tommorow :)
Re: Multi Language Error Documents
Posted by Marc Slemko <ma...@znep.com>.
On Sun, 19 Aug 2001, William A. Rowe, Jr. wrote:
> 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 :)
Note that this doesn't work when people do silly things like use
"/index.html" instead of "/". Typically many people creating content use
the two interchangeably. But that's ok, I think... since random people
shouldn't be making documents linking to the default index page.
Although we should perhaps make sure there are no silly links in the docs
that reference /index.html.
Hrm. When you committed the DirectoryIndex change, you did .html.var
first then .html. Shouldn't it be the other way around (like you stated
above)? In the current order, if someone sticks there own index.html in
there, it will not behave entirely as expected in odd (to the user)
ways...
So I like the idea of using a type map so multiviews don't have to be
enabled for "/". The performance for / requests will still be
Leaving multiviews enabled for the docs subtree is ok from a performance
and random bugs standpoint... there are still possibilities for security
issues, but they should be minimal.
So I like this direction... thanks.
But... we still have the original question of the multi-lingual error
messages, and if they should be enabled by default and, if so, then how.
<g>
---------------------------------------------------------------------
To unsubscribe, e-mail: apache-docs-unsubscribe@apache.org
For additional commands, e-mail: apache-docs-help@apache.org
Re: Multi Language Error Documents
Posted by Marc Slemko <ma...@znep.com>.
On Sun, 19 Aug 2001, William A. Rowe, Jr. wrote:
> 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 :)
Note that this doesn't work when people do silly things like use
"/index.html" instead of "/". Typically many people creating content use
the two interchangeably. But that's ok, I think... since random people
shouldn't be making documents linking to the default index page.
Although we should perhaps make sure there are no silly links in the docs
that reference /index.html.
Hrm. When you committed the DirectoryIndex change, you did .html.var
first then .html. Shouldn't it be the other way around (like you stated
above)? In the current order, if someone sticks there own index.html in
there, it will not behave entirely as expected in odd (to the user)
ways...
So I like the idea of using a type map so multiviews don't have to be
enabled for "/". The performance for / requests will still be
Leaving multiviews enabled for the docs subtree is ok from a performance
and random bugs standpoint... there are still possibilities for security
issues, but they should be minimal.
So I like this direction... thanks.
But... we still have the original question of the multi-lingual error
messages, and if they should be enabled by default and, if so, then how.
<g>
Re: Multi Language Error Documents
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Lars Eilebrecht" <la...@hyperreal.org>
Sent: Sunday, August 19, 2001 3:36 PM
> According to William A. Rowe, Jr.:
>
> > Could this solution presuade everybody between 0 and +1 for negotated
> > content?
>
> +1 on the concept!
I have to grab groceries and my kids (in two different directions.) This patch
might not be ready till tommorow morning. I'm then wrapping up this question of
falling back to lang if lang-var isn't found, then falling back on LanguagePriority
if the admin sets ForceLanguagePriority on.
Bill
Re: Multi Language Error Documents
Posted by Lars Eilebrecht <la...@hyperreal.org>.
According to William A. Rowe, Jr.:
> Could this solution presuade everybody between 0 and +1 for negotated
> content?
+1 on the concept!
ciao...
--
Lars Eilebrecht - A clean, neat, and orderly work place
lars@hyperreal.org - is a sure sign of a sick mind.
Re: Multi Language Error Documents
Posted by Lars Eilebrecht <la...@hyperreal.org>.
According to William A. Rowe, Jr.:
> Could this solution presuade everybody between 0 and +1 for negotated
> content?
+1 on the concept!
ciao...
--
Lars Eilebrecht - A clean, neat, and orderly work place
lars@hyperreal.org - is a sure sign of a sick mind.
---------------------------------------------------------------------
To unsubscribe, e-mail: apache-docs-unsubscribe@apache.org
For additional commands, e-mail: apache-docs-help@apache.org
Re: Multi Language Error Documents
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Marc Slemko" <ma...@znep.com>
> 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
Re: Multi Language Error Documents
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Marc Slemko" <ma...@znep.com>
> 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: apache-docs-unsubscribe@apache.org
For additional commands, e-mail: apache-docs-help@apache.org
Re: Multi Language Error Documents
Posted by Martin Kraemer <Ma...@Fujitsu-Siemens.com>.
On Sun, Aug 19, 2001 at 11:24:19AM -0700, Marc Slemko wrote:
> 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.
OTOH they *might* be especially useful in these situations, even if
the site has (almost?) no other file(s) in the requester's language.
I don't have any chinese files on my server, but if a chinese reader
requests a file which he does has no right to access, he would be
happy to see a chinese error telling hime so.
But I totally agree with the reluctance performance-wise.
> 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...
Based on the note I wrote for the apache manual pages a couple of
years ago, I still often get feedback from apache users who actually
use the feature, and would like a more obvious and easy interface
to take advantage of it.
Martin
--
<Ma...@Fujitsu-Siemens.com> | Fujitsu Siemens
<ma...@apache.org> | 81730 Munich, Germany
Re: Multi Language Error Documents
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: <ia...@covalent.net>
Sent: Sunday, August 19, 2001 3:30 PM
> And a little nit...
>
> Apart from the security and performance concerns of having multiviews on
> by default, there's the little problem I've noticed that recent MSIE
> vintages seem to be sending "en-us" as its default language, not "en", so
> the distributed config should really have
> AddLanguage en-us .en
absolutely -1. See my detailed answer to Rich Bowen's question on httpd-docs.
> added to the list so as to not confuse newcomers at the splash screen,
> they don't get the index.html.en by default.
They should. We should fall back on foo if foo-var isn't found. If that's
not happening, we have a bug.
Re: Multi Language Error Documents
Posted by "Ian Kallen <iank@covalent.net>" <ia...@covalent.net>.
And a little nit...
Apart from the security and performance concerns of having multiviews on
by default, there's the little problem I've noticed that recent MSIE
vintages seem to be sending "en-us" as its default language, not "en", so
the distributed config should really have
AddLanguage en-us .en
added to the list so as to not confuse newcomers at the splash screen,
they don't get the index.html.en by default.
On Sun, 19 Aug 2001, Marc Slemko wrote:
> > 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
cheers,
-Ian
--
Ian Kallen <ia...@covalent.net> | AIM: iankallen
---------------------------------------------------------------------
To unsubscribe, e-mail: apache-docs-unsubscribe@apache.org
For additional commands, e-mail: apache-docs-help@apache.org
Re: Multi Language Error Documents
Posted by "Ian Kallen <iank@covalent.net>" <ia...@covalent.net>.
And a little nit...
Apart from the security and performance concerns of having multiviews on
by default, there's the little problem I've noticed that recent MSIE
vintages seem to be sending "en-us" as its default language, not "en", so
the distributed config should really have
AddLanguage en-us .en
added to the list so as to not confuse newcomers at the splash screen,
they don't get the index.html.en by default.
On Sun, 19 Aug 2001, Marc Slemko wrote:
> > 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
cheers,
-Ian
--
Ian Kallen <ia...@covalent.net> | AIM: iankallen