Hallo liebe Apache User,
kurz-Version:
Bei Options +MultiViews und mehreren Sprachen + Typen + Encodings zur Auswahl
erhÃlt ein Browser bei nicht-passender Sprache nicht eine Alternative nach
der LanguagePriority, sondern ein 406-Response. Wie kann ich der
LanguagePriority einen hÃheren Stellenwert einrÃumen, um die 406-Response zu
vermeiden? Oder gibt es eine andere MÃglichkeit, statt einer 406-Response
eine nicht zum Accept-Language-Header passende Response (anderer
Content-Language-Header) zu senden?
lang-Version:
ich habe lange Zeit experimentiert, um eine optimale Konfiguration fÃr
Mehrsprachigkeit sowie HTML/XHTML zu erhalten. Im WWW waren natÃrlich auch
Klasse Tipps zu finden.
Ich verwende nun folgende .htaccess (Auszug) im Root-Directory meines
VirtualHosts:
Options +MultiViews +Includes
AddType text/html;charset=US-ASCII .html
AddType application/xhtml+xml;charset=UTF-8;qs=0.999 .xhtml
AddLanguage de .de
AddLanguage en .en
LanguagePriority de en
Die text/html-Dateien sind gÃltige HTML 4.01-Dateien in US-ASCII, die
application/xhtml+xml-Dateien sind gÃltige XHTML 1.1-Dateien in UTF-8.
Die Dateien fÃr die Sprachen sind dann in eigenen Verzeichnissen, de/ fÃr die
deutschsprachigen, en/ fÃr die englischsprachigen usw..
Lediglich die Sprachauswahl der Startseite wird Ãber MultiViews geliefert:
index.de.html
index.de.html.gz
index.de.xhtml
index.de.xhtml.gz
index.en.html
index.en.html.gz
index.en.xhtml
index.en.xhtml.gz
de/seite1.html
de/seite1.html.gz
de/seite1.xhtml
de/seite1.xhtml.gz
...
en/page1.html
en/page1.html.gz
en/page1.xhtml
en/page1.xhtml.gz
...
Die Links zeigen immer auf die Basis des MultiViews, z.B. .../de/seite1.
Das Problem, dass man dann nicht einfach in der URL en durch de bzw. umgekehrt
ersetzen kann, wollte ich dadurch umgehen, dass ich mit RewriteRules arbeite,
musste dann aber feststellen, dass der Webhoster das nicht unterstÃtzt -
Pech, das tut aber nichts zur Sache.
Damit der Content-Language-Header bei den Seiten dennoch mitgeliefert wird,
wollte ich nun in jedem Sprachverzeichnis eine .htaccess-Datei folgendem
Eintrag vornehmen (Beispiel fÃr de/):
AddLanguage de .html
AddLanguage de .xhtml
Das fÃhrt jedoch dazu, dass ein Browser, der nicht de im Header
Accept-Language sendet, statt einer Seite ein 406 Not Acceptable mit einer
Auswahl bekommt, z.B.:
Available variants:
* start.html , type text/html, language de, charset us-ascii
* start.html.gz , type text/html, language de, charset us-ascii, encoding
gzip
* start.xhtml , type application/xhtml+xml, language de, charset utf-8
* start.xhtml.gz , type application/xhtml+xml, language de, charset utf-8,
encoding gzip
Ich habe schon versucht, mit DefaultLanguage statt AddLanguage zu arbeiten.
Das Ergebnis ist aber das gleiche, der Client erhÃlt einen 406-Response, wenn
er die Sprache nicht in Accept-Language sendet.
Ich habe auch Teile des RFC 2616 (HTTP/1.1) gelesen, um eine Antwort zu
finden, ob es einem Server Ãberhaupt erlaubt ist, einen Response auÃerhalb
des durch die Accept-Header eingeschrÃnkten Bereichs zu liefern, und
folgenden Hinweis gefunden:
"Note: HTTP/1.1 servers are allowed to return responses which are
not acceptable according to the accept headers sent in the
request. In some cases, this may even be preferable to sending a
406 response. User agents are encouraged to inspect the headers of
an incoming response to determine if it is acceptable."
[ftp://ftp.rfc-editor.org/in-notes/rfc2616.txt 10.4.7 406 Not Acceptable]
Ich denke, mein Problem fÃllt ganz definitiv unter "this may even be
preferable". Wenn ein Benutzer schon im de/-Bereich ist, sein User-Agent aber
kein de im Accept-Language hat, hat der Benutzer sich wahrscheinlich
selbstÃndig fÃr Deutsch als Sprache entschieden.
AuÃerdem kann es ja sein, dass ein User-Agent weder de noch en in den
Accept-Language-Header eintrÃgt. Insbesondere dann wÃre die (offensichtlich
nicht meiner Erwartung gemÃÃ stattfindende) Auswertung der
LanguagePriority-Direktive gegenÃber einer 406-Response zu bevorzugen.
Ich kann dabei auch nicht verstehen, warum in der Dokumentation zum
Apache-Modul mod_negotiation Ãber die LanguagePriority-Direktive zu lesen
ist: "[...] Correctly implemented HTTP/1.1 requests will mean this directive
has no effect."
NatÃrlich kÃnnte ich auch darauf verzichten, das Problem zu lÃsen, praktisch
kann ich prima mit der aktuellen Situation (kein Content-Language-Header fÃr
die Dateien in den Sprach-Verzeichnissen) leben, zumal die Sprachinformation
ja zusÃtzlich als xml:lang-Attribut (XHTML) bzw. lang-Attribut (HTML) in den
Dateien vorhanden ist. Theoretisch bin ich aber Perfektionist und wÃrde gerne
einen 100% korrekten und darÃber hinaus vollstÃndigen Header senden, sprich,
ich will also einen nicht zum Accept-Language passenden
Content-Language-Header senden statt einer 406-Response.
Nun also zu meiner Frage:
Gibt es eine MÃglichkeit, Apache so zu konfigurieren, dass bei den MultiViews
fÃr den Fall, dass die Sprache fÃr den Client nicht passt, die
LanguagePriority-Direktive in der Konfiguration so hohen Stellenwert bekommt,
dass bei nicht-vorhandener Sprache statt einer 406-Response die Alternative
anhand der LanguagePriority-Direktive ausgewÃhlt wird? Oder gibt es
stattdessen eine andere Alternative?
Weià jemand Rat?
SchÃne GrÃÃe
--
ITCQIS GmbH
Christian Wolfgang Hujer
GeschÃftsfÃhrender Gesellschafter
Telefon: +49 (0)89 27 37 04 37
Telefax: +49 (0)89 27 37 04 39
E-Mail: [EMAIL PROTECTED]
WWW: http://www.itcqis.com/
--------------------------------------------------------------------------
Apache HTTP Server Mailing List "users-de"
unsubscribe-Anfragen an [EMAIL PROTECTED]
sonstige Anfragen an [EMAIL PROTECTED]
--------------------------------------------------------------------------
