You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@httpd.apache.org by Lars Eilebrecht <la...@hyperreal.org> on 2001/08/19 03:42:29 UTC
Multi Language Error Documents
Hi guys,
as requested, I've committed my current version (with a few
changes) of the multi language error documents to httpd-docs-2.0.
Although I haven't yet seen the commit email. Hmm...
We could add it to 1.3 aswell, but I think we should just
focus on 2.0 here and use my stuff as a base and improve it
for the final 2.0 version.
Please note that I've not yet verified functionality with
2.0, but just 1.3.
If you would like to test it with either 1.3 or 2.0 make
sure you got the following directives in your httpd.conf:
<Directory /path/to/htdocs/error>
Options +FollowSymLinks +Includes -Indexes +MultiViews
AddHandler server-parsed .html
order allow,deny
allow from all
</Directory>
ErrorDocument 400 /error/bad_request
ErrorDocument 401 /error/auth_required
ErrorDocument 403 /error/forbidden
ErrorDocument 404 /error/not_found
ErrorDocument 405 /error/method_not_allowed
ErrorDocument 408 /error/request_timeout
ErrorDocument 410 /error/gone
ErrorDocument 411 /error/length_required
ErrorDocument 412 /error/precondition_failed
ErrorDocument 413 /error/entity_too_large
ErrorDocument 414 /error/uri_too_large
ErrorDocument 415 /error/unsupported_media_type
ErrorDocument 500 /error/internal_server_error
ErrorDocument 501 /error/not_implemented
ErrorDocument 502 /error/bad_gateway
ErrorDocument 503 /error/service_unavailable
ErrorDocument 506 /error/variant_also_varies
AddLanguage de .de
AddLanguage en .en
AddLanguage fr .fr
AddLanguage es .es
LanguagePriority en de fr es
BTW, some of the error docs are referencing "/error/...",
so it's not easily possible to change the path.
The files "/error/*.xx.html" contain the actual error texts
and some server-side include commands (the files without any
language extension are a symlink to the english version, they
are served if the client has none of the available languages
in his accept-language header; at least for Apache 1.3 this
was kind of a 'feature').
There is almost no HTML markup in these files.
The real HTML markup has been seperated in a few files located
in the directory "/error/includes".
Things to do:
- Discuss if we want to continue with the current concept
of the files in /error/includes?
IMHO the current
- Add documents for any new error in 2.0
(e.g., all the new DAV errors)
- Some of the document could be enhanced by using some
new env variables, e.g., the NOTES stuff. IIRC this could
be very useful for the proxy messages.
- After his has been done, start adding other languages
Currently we have English, German, French and Spanish.
ciao...
--
Lars Eilebrecht - "No maintenance": Impossible to fix.
lars@hyperreal.org
---------------------------------------------------------------------
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 Lars Eilebrecht <la...@hyperreal.org>.
According to Rodent of Unusual Size:
> Lars Eilebrecht wrote:
> >
> > We already activate MultiViews by default
>
> We do?
Yes, we define "Options Indexes FollowSymLinks MultiViews"
for "/".
ciao...
--
Lars Eilebrecht - Computers are not intelligent.
lars@hyperreal.org - They only think they are.
---------------------------------------------------------------------
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 Rodent of Unusual Size <Ke...@Golux.Com>.
Lars Eilebrecht wrote:
>
> We already activate MultiViews by default
We do?
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"All right everyone! Step away from the glowing hamburger!"
---------------------------------------------------------------------
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 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 "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
Re: Multi Language Error Documents
Posted by Marc Slemko <ma...@znep.com>.
(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.
---------------------------------------------------------------------
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>.
(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 Lars Eilebrecht <la...@hyperreal.org>.
According to William A. Rowe, Jr.:
> Second, some platforms don't have symlinks, that won't work.
Well, the files are now actually copies of the english variant
in the CVS repository.
> And the ForceAcceptableLanguage patch will go in Monday, so the user gets
> 'something'.
I'm +1 on such a patch (has been requested by users very often in the past),
but IMHO we shouldn't activate it by default, because AFAIK it violates
the RFC.
> > 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.
ciao...
--
Lars Eilebrecht - Modesty: Being comfortable that others
lars@hyperreal.org will discover your greatness.
---------------------------------------------------------------------
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: "Joshua Slive" <jo...@slive.ca>
Sent: Saturday, August 18, 2001 10:26 PM
> On Sun, 19 Aug 2001, Lars Eilebrecht wrote:
>
> > Hi guys,
> >
> > as requested, I've committed my current version (with a few
> > changes) of the multi language error documents to httpd-docs-2.0.
> > Although I haven't yet seen the commit email. Hmm...
>
> Looks good from here. I haven't tested them yet, but the
> concept looks right to me.
Looks great here too ... except that we should figure out how to 'roll these together'
into some tighter package. This list is way long :)
> > The files "/error/*.xx.html" contain the actual error texts
> > and some server-side include commands (the files without any
> > language extension are a symlink to the english version, they
> > are served if the client has none of the available languages
> > in his accept-language header; at least for Apache 1.3 this
> > was kind of a 'feature').
>
> I don't believe this will work in 2.0 since the mime handling
> revamp by OtherBill. I think it is very important that
> somebody fixes this in some way, but I'm not going to do it.
> The suggested solution was to add a ForceAcceptableLanguage
> directive that would cause Apache to use the LanguagePriority
> to decide what language to deliver if it can't find an
> acceptable variant.
It's borked two ways (one all the way back to 1.3). First, the trailing
.html clobers the content-language/content-type, since it overwrites the
entire content-type string. I was meaning to get this fixed anyways.
Second, some platforms don't have symlinks, that won't work. And the
ForceAcceptableLanguage patch will go in Monday, so the user gets 'something'.
> 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 :)
Bill
---------------------------------------------------------------------
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 Joshua Slive <jo...@slive.ca>.
On Sun, 19 Aug 2001, Lars Eilebrecht wrote:
> Hi guys,
>
> as requested, I've committed my current version (with a few
> changes) of the multi language error documents to httpd-docs-2.0.
> Although I haven't yet seen the commit email. Hmm...
Looks good from here. I haven't tested them yet, but the
concept looks right to me.
> BTW, some of the error docs are referencing "/error/...",
> so it's not easily possible to change the path.
I think we should probably change absolute references. I don't
mind leaving them in "error", but it would be good to give
the webmaster the flexibility to move them if they wish.
> The files "/error/*.xx.html" contain the actual error texts
> and some server-side include commands (the files without any
> language extension are a symlink to the english version, they
> are served if the client has none of the available languages
> in his accept-language header; at least for Apache 1.3 this
> was kind of a 'feature').
I don't believe this will work in 2.0 since the mime handling
revamp by OtherBill. I think it is very important that
somebody fixes this in some way, but I'm not going to do it.
The suggested solution was to add a ForceAcceptableLanguage
directive that would cause Apache to use the LanguagePriority
to decide what language to deliver if it can't find an
acceptable variant.
>
> Things to do:
>
> - Discuss if we want to continue with the current concept
> of the files in /error/includes?
> IMHO the current
I think you missed a thought here. Anyway, I am fine
with how it works at the moment.
Another entry for the todo list:
- Add the config for this to httpd-std.conf. I believe
that we should enable it by default.
I'm offline tomorrow. (All day power outage in the building holding
my mail server. Hrumph!) But I'll take a more detailed look next
week.
Joshua.
---------------------------------------------------------------------
To unsubscribe, e-mail: apache-docs-unsubscribe@apache.org
For additional commands, e-mail: apache-docs-help@apache.org