webserver requirements (was: PR 25 and PR 68)

Werner Koch wk@gnupg.org
Sun, 25 May 2003 22:47:57 +0200


On Thu, 22 May 2003 23:28:48 +0200, Lorenzo Cappelletti said:

> The best would be to definitely switch to Apache.  But this involves 
> aegypten subdirs, as well.  Werner, did you have some thoughts about it?  
> Once, you told me that latest Caudium releases should support Apache's 
> *.xx.html scheme...

I just read the Apache docs agains and I could find anything about a
foo.ll.html scheme for i18n.  They say, one should append the country
code like foo.html.en .  I find this counterintuitive because the
usual way for documents is foo.xx.whatever_extension_you_use - iirc,
this is how the aegypten files are organized.  Is Apache able to
handle this?

My proposal is to switch to another webserver.  I use Boa for quite
some time and after some recent fixes it is really stable and works
well for static pages.  CGI support is also quite okay.  The reason
for Boa is, that it is very well written and thus easy to fix and
well, it is not such a resource hog as Caudium or Apache. 

A couple of days ago, I implemented experimental i18n support and it
worked like a charm.  The question is how it should really work ;-)
Here are my thoughts:

 1. We need only html files but have no need for other file types for
    now.  It won't be hard to add other types, though.

 2. When asked for foo.ll.html the server should return foo.ll.html or
    in case this does not exists foo.html .

 3. When asked for foo.html the server should look at the the
    Accept-Language header and return foo.ll.html with a best matching
    ll .  If it is not found foo.html is served.

So we rely on the Accept-Language header for initial selection of the
language if links don't specify a specific language.  This has the
problem that a user can't arbitrary select a language from the webpage
- so we should make sure that we always link to the correct language
file (<a href="foo.es.html">) with the minor problem that a reference
to a non-existing file falls back to foo.bar which points to
foo.en.bar and from then on the user accidently stays with that
language.  Because we generate the files, we can make sure, this never
happens.

We might want to have a default fallback of "foo.en.html" so that we
don't need the symlinks.

Before you ask: The full content negotation burns a lot of CPU due to
frequent system calls - something I would really like to avoid.

Comments?


-- 
  Nonviolence is the greatest force at the disposal of
  mankind. It is mightier than the mightiest weapon of
  destruction devised by the ingenuity of man. -Gandhi