Es ist nun schon einige Zeit ins Land gegangen, seit das zuletzt beschriebene Login-Problem unter dem Browser Konqueror aufgetreten ist. Es gab auch einen erfreulich regen Austausch mit einem der KDE-Entwickler.

Leider haben die bisherigen Korrekturen zum korrekten Parsing von HTTP-Headern das Problem nicht behoben. Im Moment steht nur soviel fest:

1) Meine eigenen Tests in unserem Firmennetzwerk (mittels einiger PHP-Programme und einer Paketanalyse mit Wireshark) zur Interpretation von HTTP Redirect-Anforderungen (Refresh, Location – Direktiven) durch den Browser Konqueror sind alle positiv verlaufen. Daran scheint es also nicht zu liegen.
2) Die vom OX5-Server im Redirect angeforderten Cookies werden korrekt gesetzt. Der xhtml-Inhalt der HTTP – Refresh-Anforderung an den Browser wird korrekt dargestellt – der Refresh wird jedoch nicht mehr durchgeführt. Es wird kein entsprechendes HTTP GET – Paket an den Server zurückgesandt.
3) Das Problem tritt definitiv erst nach der ab Version 3.5.7-64.1 des kdebase3- bzw. des kdelibs3-Paketes auf. Nachweislich nicht nur auf meiner Installation. Es hat auch nichts mit der bei uns eingesetzten 64Bit Architektur zu tun.
4) Es ist unklar, wie Konqueror mit “chunked” Inhalt der HTTP-Pakete umgeht (“Transfer-Encoding: chunked”). Interessanterweise versendet der OX5 Server seine Mitteilungen an den Browser auf diese Weise. Mir drängt sich ein wenig der Verdacht auf, dass es evtl. ein Konqueror-Problem geben könnte, wenn die vorgegebenen “chunks” alle in einem einzigen IP-Paket Platz finden. Aber das müssen die KDE-Leute herausfinden.

Zusatzanmerkung:
Angesichts der seit 11. August geltenden Rechtslage (Strafrecht §202c) möchte ich betonen, dass eine gründliche Analyse des Problems eigentlich nur unter Beobachtung des Paketaustausches zwischen Client und Server möglich ist. Ich habe mir deshalb wegen der neuen Gesetzgebung als Inhaber der Firma selbst und höchst offiziell die Erlaubnis erteilt, in meiner zweiten Rolle als Administrator die Paketverfolgung in unserem firmeneigenen Netzwerk temporär und auf 2 Rechner begrenzt durchzuführen und danach alle eingesetzten Hilfsmittel wieder von den Systemen zu entfernen.

Wer das für schwachsinnig hält, hat zwar irgendwie Recht, möge sich aber bitte mal mit der neuen Rechtslage auseinandersetzen – danach stellt womöglich allein der Besitz von solchen Analyse-Tools ein Gesetzesvergehen dar (siehe etwa entsprechende Artikel in den letzten Ausgaben des Linux-Magazins oder aber aktuelle Artikel im PC Magazin) .

Diesem Wahnsinn haben übrigens alle Parteien außer der PDS im Bundestag zugestimmt. Wer also gegen die völlig diffuse Ausformulierung des §202c noch nicht beim Bundestagsabgeordneten seines Vertrauens protestiert hat, sollte dies nachholen. Hier ist insgesamt eine sehr ungute Entwicklung im Gang, die man als IT-Fachfrau oder -mann und als Demokrat nur mit allergrößtem Misstrauen beobachten kann. Hierzu schreibe ich aber bei Gelegenheit einen separaten Beitrag.

Wie man der Kommunikation zu den Konqueror-Bugs

http://bugs.kde.org/show_bug.cgi?id=150070 und http://bugs.kde.org/show_bug.cgi?id=149957

entnehmen kann, gibt es seit ein paar (Entwicklungs-) Versionen wohl tatsächlich Schwierigkeiten bei der Interpretation von HTTP Header Direktiven. Es handelt sich dann also nicht um ein OX5 spezifisches Problem des Browsers Konqueror.

Die KDE-Entwickler arbeiten anscheinend daran – das ist beruhigend, obwohl man sich natürlich fragt, wie denn die Tests aussehen, wenn in einen so wichtigen Bereich eines Browsers eingegriffen wurde. Auf der anderen Seite führt aber auch nicht jeder Benutzer mit so hoher Frequenz wie ich ein Update der KDE Umgebung durch.

Betrachten wir das Ganze also mal als Test, wie denn die Opensource Gemeinde mit so einem Problemchen umgeht. Ich bin jedenfalls gespannt, ob und in welcher der nächsten Versionen der von SUSE publizierten KDE rpms dieser Fehler behoben sein wird.

Ergänzung:
Mir ist bei der Analyse des HTTP-Datenverkehrs zwischen OX-Server und Browser (mittels Wireshark) aufgefallen, dass die OX-Leute für den Redirect im Login-Prozess eine “REFRESH”-Direktive im HTTP-Header benutzen. Das ist insofern bemerkenswert, als dies kein HTTP 1.1-Standard ist, wenngleich diese Direktive von Firefox, IE und Opera unterstützt wird. Bis zur Version 3.5.7-64.1 wohl eben auch von Konqueror. Nur danach halt leider nicht mehr!

Eine Lehre, die sich an diesem Beispiel erneut bestätigt, ist die Folgende:

Gerade beim produktiven Einsatz von Opensource muss jedes Update des Desktops vor dem Produktiv-Einsatz gründlich auf die Funktionstüchtigkeit der Standard-Arbeitsabläufe hin getestet werden. Es wird keineswegs alles besser, wenn ein neues (Zwischen-) Release auf den Markt kommt.    

Ein permanentes Ärgernis beim Einsatz von Open-Xchange unter Linux sind Unzulänglichkeiten, die im Zusammenhang mit dem Standard KDE (Web-) Browser Konqueror auftauchen.
Das neueste Beispiel ist ein fehlerhafter Login-Vorgang, bei dem Konqueror die Anforderungen des Servers nicht richtig handhabt. Ich beschreibe kurz das Problem, so wie es sich mir darstellt:

Ein Login auf dem Open-Xchange Server setzt wie üblich die Angabe einer Userid und eines Passwortes voraus. Der OX-Server (bzw. das dortige Sessionmanagement) vergeben eine SessionId. Dies wird dem Client zurückgemeldet und daraufhin wird ein Redirect zu einem Servlet des Servers vorgenommen, dass dafür sorgt, dass die Portalseite des Servers für den authentifizierten User aufgebaut und dem Client übermittelt wird. (Ich vermute, dass nach der Vergabe der SessionId der Client aufgefordert wird, die User-Daten nochmal zu übermitteln.)

Bis zur kdebase-Version 3.5.7-64.1 (in meinem Fall über ein SuSE x86-64 rpm unter Opensuse 10.2 eingespielt) lief dieser Login-Vorgang einwandfrei. In der neuesten Version 3.5.7-90.2 klappt dies jedoch nicht mehr. Es erfolgt zwar noch die Anzeige der Meldung, dass eine SessionId vergeben wurde, der anschließende Redirect wird aber nicht mehr ausgeführt und die Portalseite wird nicht angezeigt. Interessanterweise kommt man weiter, wenn man die Seite mit der redirect-Meldung nochmal lädt -> Die Login-Daten des usprünglichen Formulars werden nochmals geschickt, eine neue SessionId wird vergeben und die Portalseite erscheint unmittelbar danach.

Weder Firefox noch Opera zeigen ein derartiges Verhalten.

Wie man der Bug-Datenbank zu Konqueror entnehmen kann, gab es bereits in früheren Versionen von Konqueror Probleme mit Redirects (auch im Zusammenhang mit Authentifizierungs-Dialogen).

Es ist ärgerlich, dass solche Problemchen immer wieder auftauchen und einen flüssigen, produktiven Arbeitsablauf unter Linux (KDE) verhindern. Da es noch weitere Probleme im Zusammenspiel zwischen Konqueror und einem OX5-Server gibt (siehe weitere kommende Beiträge in diesem Blog), rate ich jedem OX5-User eher auf Firefox oder Opera als CLient-Browser zu setzen.