MultiViews mit Apache 1.3

[Gunnar Bittersmann]

@@Edgar Ehritt:

Jedenfalls ist sowohl 'application/xhtml+xml;charset=iso-8859-1;qs=0.999' als auch 'text/html; charset=UTF-8' kein gültiges MIME-Type. Das der Apache daraus den Header 'Content_Type' erstellt, ohne weitere Analyse zu betreiben, ist nur sehr sehr kurzsichtig gedacht. Wenn Du mir anhand des Quellcodes vom Apachen in allen drei Publikationsversionen zeigst, dass dies nicht nur möglich ist, sondern auch konsequenzenlos bei der Verarbeitung der intern vom Server geführten Tabelle (ap_get_table()) bleibt, die für andere Module (API) wichtig ist, winke ich zukünftig auch mit dem Fähnchen.

Ich hatte bewusst vorsichtig formuliert: „Der W3C-I18n-Artikel Einstellung der Zeichencodierungsangabe ('charset') in .htaccess sagt […] etwas anderes.“ Nicht „... sagt es richtig.“

Heißt das, die Angabe von 'charset' in 'AddType' funzt zwar, verlassen sollte man sich aber nicht darauf, weil es nicht der Apache-Spezifikation entspricht?

Sollte ich den Autor des Artikels mal darauf hinweisen?

http://www.edition-w3c.de/TR/2002/REC-xhtml1-20020801/#heading-3� (5.)

"Zwingend" muss ich also in dem Sinne zurück nehmen, weil es eben heißt: "Den Autoren von XHTML-Dokumenten wird jedoch sehr empfohlen, in all ihren Dokumenten XML-Deklarationen zu verwenden."

Die Rechnung wurde ohne den Wirt^W^Weinen gewisse Clienten gemacht: IE < 7. Da diese bei XML-Deklaration in den Quirks-Modus schalten, war diese Empfehlung in der XHTML-Spezifikation noch nie wirklich sinnvoll.

Aber in Verbindung mit dem Verhalten des Apachen, für MIME-Type application/xhtml+xml kein charset im Content-Type-Header anzulegen, ist dies -best practice-.

Warum sollte man den Server nicht dazu bewegen, für XHTML als 'application/xhtml+xml' die Zeichencodierung im Header anzugeben?

qs ist eine RFC-spezifizierte Variable zur Berechnunsdemonstration; q gibt es in HTTP-Headern!

Was ein kleines 's' für einen Unterschied macht. Den hatte ich in der Tat übersehen.

Live long and prosper,
Gunnar