httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: I18N Server Side support for OS running foreign locale
Date Sat, 22 Sep 2001 01:54:37 GMT
> From: "Vaughn, Louis" <>
> Sent: Wednesday, April 11, 2001 10:16 AM
> To: ''
> Subject: I18N Server Side support for OS running foreign locale
> Greetings,
> First please note that I spent a good bit of time searching the FAQ's & User
> archives before sending you this question.
> Does Apache support I18N characters in server side path names, host name,
> etc. for various foreign languages (e.g. zh_TW, JA, etc), (i.e. not just
> document content)?
> If not, will this be coming any time soon?
> If so, how do I specify the locale for httpd at startup (i.e. is there a
> locale directive for httpd; I've looked and can't find one)?

As Roy Fielding pointed out on the list, Apache does not support wchar 
Unicode (except as http body content served to a client, note the 
distributed example document htdocs/

Apache also does not (yet) 'transparently' support any of the i18n forms 
of the server (host) name.  Since most are encoded into an ASCII subset,
it should be trivial to drop their 'encoded' forms as ServerName or 
ServerAlias directives (but the encoded forms are essentially illegible.)

Apache will never have a 'locale' as such.  Web servers themselves are
effectively language/content neutral.  You can define directives such
as DefaultLanguage to declare that documents (e.g. .html files) are in
a given language, etc.

Most unixes and (as of Apache 2.0) Windows NT will support virtually any
characters in the filename, when using utf-8 unicode encoding.  There
will be additional features in the coming Apache 2.0 to declare the
language of the mod_autoindex results.  Encoding anchor href's in html
documents correctly is up to the author.

Recognize that HTTP/1.1 _never_ defined the encoding for non-ascii requests.
There is no standard, although most momentum is twords %-escaped, utf-8
encoded Unicode URI representations.

So for the most part, today Apache 1.3 on unix is nominally flexible for
i18n applications, in that there are really no restrictions on how you 
configure the server with ErrorDocument files, etc.  Apache 2.0 will make 
several aspects much simpler.  Utf-8 for URI encoding grants more recent 
browsers a real charset/language neutral window to the server.  It already 
has four common european languages for *client* error message translations 
(e.g. 404 Not found, with an explanation, is translated for dk, es, and fr
browsers and their users.)

I'm sure that's more than you wanted to know, and I probably missed some
of the gist of your question.  Please feel free to follow up, i18n itself
is an overly broad question.


View raw message