RootForum Community

Distribution: Debian Lenny, Apache Version folglich 2.2.9

Auf dem Server läuft ein Apache als Reverse Proxy. mod_proxy_html schreibt die Links in den HTML Seiten um, und konvertiert die Dokumente dabei von ISO-8859-1 nach UTF-8 (http://apache.webthing.com/mod_proxy_html/faq.html).
Damit der Inhalt von POST Forms korrekt verarbeitet werden kann (auf die charset Angabe ist kein Verlass: http://cwiki.apache.org/WICKET/how-to-c ... oding.html), muss das Ergebnis zurück in ISO-8859-1 konvertiert werden.
Dafür möchte ich gerne mod_charset_lite benutzen.
Aber obwohl das Modul geladen ist (Ausgabe von apache2 -t -D DUMP_MODULES), macht es allem Anschein nach nichts.

Beabsichtigte Konfiguration in /etc/apache2/apache2.conf:
SetOutputFilter proxy-html;XLATEOUT
#->transform back to ISO-8859-1
CharsetSourceEnc UTF-8
CharsetDefault ISO-8859-1
CharsetOptions DebugLevel=1 NoImplicitAdd

Da tritt aber auch schon das erste Problem auf: Der Neustart von Apache scheitert mit "Invalid CharsetOptions option: NoImplicitAdd". Google spuckt für diesen Fehler keinen einzigen Treffer aus... ](*,)
Entferne ich die Option NoImplicitAdd, so startet Apache, aber schreibt keinerlei Debugmeldungen für mod_charset_lite, und ändert eben auch die Kodierung nicht. :(

Bin für jeden Hinweis dankbar...
(Ist bestimmt was relativ simples, aber ich komm halt partout nicht drauf, und nach einem Tag erfolgloser Versuche macht es langsam keinen Spaß mehr.)

Damit der Inhalt von POST Forms korrekt verarbeitet werden kann [...], muss das Ergebnis zurück in ISO-8859-1 konvertiert werden.

Wenn du den Request-Body konvertieren möchtest, kommst du aber mit einem Outputfilter nicht weit. Da müsstest du schon den Inputfilter nehmen.

Das wäre eine Alternative, ja. Bisher habe ich vor, via Outputfilter dafür zu sorgen, dass der Browser ISO-8859-1 erhält. Browser richten sich nach dem Zeichensatz der dargestellten Seite, um zu entscheiden, in welchem Zeichensatz sie die Antwort zurücksenden (POST).

Und für den Inputfilter wäre ja ebenfalls mod_charset_lite zuständig, richtig (XLATEIN)? Ich denke nicht, dass das bei mir besser funktionieren würde als mein aktueller Ansatz, da ich mod_charset_lite ja bisher nicht dazu bewegen kann, mit mir zusammen zu arbeiten...

Es ist erheblich sinnvoller die WebApp(s) zu fixen, als mit mod_charset_lite herumzupfuschen, notfalls mit einem simplen accept-charset im form-element...

Würde das denn das Problem vollständig lösen? Ich finde dazu zum Beispiel:
http://www.w3schools.com/TAGS/att_form_ ... harset.asp:

The accept-charset attribute is supported by all major browsers, except Internet Explorer.
Note: The accept-charset attribute does not work properly in Internet Explorer. If accept-charset="ISO-8859-1", IE will send data encoded as "Windows-1252".

Und:
http://de.selfhtml.org/html/formulare/definieren.htm

Setzen Sie die Angaben für die Kodierung im HTTP-Header (per Serverkonfiguration - wird derzeit in SELFHTML nicht behandelt), im Seite Meta-Tag und im Attribut accept-charset auf identische Werte. Manche Browser werden verwirrt und verhalten sich u.U. unvorhersehbar, wenn sich diese drei Angaben widersprechen.

Ist das nicht mehr aktuell? Wenn sich tatsächlich alle relevanten Browser nur nach der accept-charset Angabe richten, würde es das Problem lösen.

Trotzdem sehe ich noch nicht ein, wieso ich mod_charset_lite nicht zum funktionieren bekomme. Ich habe auch versucht, TranslateAllMimeTypes als Option für CharsetOptions anzugeben, was er klaglos schluckt. Ändert aber nichts am Ergebnis. Was mir richtig Angst macht ist, dass ich einen falsch geschriebenen Filter angeben kann (habe "XLATEOU" probiert) ohne das Apache meckert. Das heißt, ich habe keine Garantie, dass er den Filter XLATEOUT überhaupt gefunden hat. :x

Und in anbetracht dessen, dass ich via Google niemanden finde, der ähnliche Probleme hat, muss ich doch eigentlich was richtig blödes falsch machen, oder? Blos was?

Danke jedenfalls für den Hinweis. Werde mal sehen ob das hinzufügen von accept-charset in den Forms der Webapp drin ist. Trotzdem will ich wissen, wie ich Apache dazu kriege, Zeichensätze umzuwandeln. Und sei es nur aus Sturrheit. :?

EDIT: Noch eine Webseite die schreibt dass IE nicht dazu zu überreden ist, eine ISO-8859-1 Angabe als accept-charset Wert zu respektieren. http://mediavrog.net/blog/2009/06/23/xh ... ttet-sind/

Also nochmal zum Mitschreiben:
In welchem Charset liegt das Dokument selbst vor?
Welches Charset ist im Dokument selbst definiert?
Welches Charset wird vom Apache definiert?
Welches Charset soll beim Client ankommen?

BTW: Kurzes Googlen und Treffer: http://nixforums.org/about18981.html letzter Post...

In welchem Charset liegt das Dokument selbst vor?
Das Dokument liegt im Charset ISO-8859-1 vor (Datei auf der Festplatte).

Welches Charset ist im Dokument selbst definiert?
Das Dokument definiert diesen Charset auch so (als ISO-8859-1).

Welches Charset wird vom Apache definiert?
Apache erkennt, dass der Filter mod_proxy_html UTF-8 benötigt, und wandelt die HTML-Daten daher in UTF-8 um (Alternativ macht es der Filter selbst als Teil seiner Arbeit. Sie werden jedenfalls genau dann umgewandelt, wenn der Filter mod_proxy_html benutzt wird. Schalte ich den Filter aus, kommt ISO-8859-1 im Browser an.)
Ein Wert für AddDefaultCharset ist nicht definiert (habe damit experimentiert: Hat den content-type HTTP Header nicht verändert).

Welches Charset soll beim Client ankommen?
Beim Client soll ISO-8859-1 ankommen.
Da der Filter mod_proxy_html benutzt werden soll (welcher UTF-8 ausspuckt) muss das Encoding zurückkonvertiert werden nach ISO-8859-1.

PS: mod_proxy_html setzt den HTTP und HTML Header nicht korrekt auf UTF-8. Firefox erkennt die tatsächliche Kodierung dennoch als UTF-8, und stellt die Seite in UTF-8 korrekt dar. Die Angabe "CharsetSourceEnc UTF-8" in apache2.conf sollte mod_charset_lite dazu bringen, die Encodierung (korrekt) als UTF-8 anzunehmen, unabhängig davon, was die Header sagen.

BTW: Kurzes Googlen und Treffer: http://nixforums.org/about18981.html letzter Post...

"Posted: Thu Mar 24, 2005"

Ich hatte diesen Thread bereits gelesen. Ich werde es nachprüfen, aber war der festen annahme, dass wenn es 2005 bemerkt und korrigiert wurde ("i have changed mod_charset_lite"), dass das Problem in der Version von Lenny behoben sei.

EDIT: Danke für den Tipp. Jetzt weiß ich wenigstens warum mod_proxy_lite nichts macht! ](*,) Die Verbesserung von 2005 scheint keinen Eingang in mod_charset_lite gefunden zu haben (man müsste dafür die Option "AllowProxied" setzen, aber die kennt Apache nicht). Bleibt die Frage: Gibt es einen Weg, den Zeichensatz von geproxieten Dokumenten zu ändern?
In der Version 3.1 von mod_proxy_html soll der Filter selbst den Output umwandeln können mithilfe von mod_xml2enc. Aber zu dem Modul finde ich so gut wie gar nichts, das scheint nur als Quellcode bestehend aus einer .c und einer .h Datei zu existieren. Keine Doku, niemand der es benutzt... Das ist keine Lösung für den produktiven Einsatz.

Problem gelöst:

"ProxyHTMLCharsetOut *" sorgt dafür, dass mod_proxy_html nach dem Umschreiben der LInks in den Ausgangszeichensatz zurückkonvertiert.

Laut http://apache.webthing.com/mod_proxy_html/faq.html sollte das ohne mod_xml2enc nicht gehen, aber scheinbar ist die FAQ nicht aktuell, und mod_xmlenc ist inzwischen irgendwo integriert. Es geht jedenfalls. :roll:

Danke für alle Hilfe! :-D

Schön das es doch noch klappt. Dennoch sollten die WebApps schleunigst fit für UTF-8 gemacht werden, Willkommen im globalen 21. Jahrhundert ;)

Hallo,

ich habe ein identisches Problem wie Thomas.

Wir nutzen einen ReverseProxy mit Hilfe von mod_proxy, mod_proxy_html und mod_xml2enc. (Links müssen übersetzt werden usw.)

Die Proxyfunktion klappt einwandfrei sowie die Linkübersetzung.
Leider hat mod_proxy_html leider zufolge, dass der Zeichensatz bei manchen Seiten mit Formularen zerschossen wird.

Die Seiten sind als ISO formatiert und deklariert.

Ich habe schon einiges probiert von "ProxyHTMLCharsetOut *", "xml2EncDefault iso-8859-1" bis hin zu der Nutzung von mod_charset_lite, was bei mir aber auch nichts bewirkt.

Ist irgendjemand bisher dahinter gestiegen und konnte das Problem lösen?

Über Hilfe würde ich mich sehr freuen!

Grüße,
Dominik