Cometvisu "spinnt" hinter proxy unter Firefox

[koend]

Moin,

wenn ich meine Visu im Win7 Firefox über meinen Proxy aufrufe, sieht's ein wenig komisch aus, siehe Anhang.
Chrome unter Android macht auch nichts, bleibt beim "Loading" hängen.

Gleiche URL im IE11 = kein Problem. Funktioniert zwar nicht alles, aber ein einfacher switch schon.

Im Firefox Browsercache geleert und "offline weg content" auch entfernt, hilft nicht. AdBlockPlus und NoScript ausgeschaltet, nada.

Visu direkt vom Wiregate ausgeliefert funktioniert prima (Firefox, Android Chrome) und kommt auch durch check_config.

Apache-Proxy neu gestartet.
Lighttpd auf wiregate neu gestartet.

Relevanter Teil der /etc/apache2/sites-enabled/default-ssl.conf:

        ProxyPass /cgi-bin http://wiregateZZZ.knet/cgi-bin
        ProxyPassReverse http://wiregateZZZ.knet/cgi-bin /cgi-bin

        ProxyPass /visu_svn/ http://wiregateZZZ.knet/visu_svn/
        ProxyHTMLURLMap http://wiregateZZZ.knet/visu_svn/ /visu_svn/
        <Location /visu_svn/>
          ProxyPassReverse http://wiregateZZZ.knet/visu_svn/
          #SetOutputFilter proxy-html
          SetOutputFilter INFLATE;proxy-html;DEFLATE
        </Location>

Ich versteh's nicht mehr... keine Ahnung woran ich noch drehen kann... :-(

Vielen Dank für eure Hilfe und Gruß

Koen

[Chris M.]

Nun, zu Deiner Server-Config kann ich nur wenig sagen - aber zum Debuggen mach mal die JavaScript-Konsole (Firebug bzw. Strg+Shift+I) auf und schau mal nach Fehlermeldungen im allgemeinen und die HTTP-Response-Codes in der Netzwerk-Sicht im speziellen.

[koend]

Nun, zu Deiner Server-Config kann ich nur wenig sagen - aber zum Debuggen mach mal die JavaScript-Konsole (Firebug bzw. Strg+Shift+I) auf und schau mal nach Fehlermeldungen im allgemeinen und die HTTP-Response-Codes in der Netzwerk-Sicht im speziellen.

Danke schön!

Habe ich gemacht, scheint am keep-alive zu hängen (siehe screenshot).

Noch ein wenig an den Apache settings gedreht: SSL aus und https://httpd.apache.org/docs/curren...ml#envsettings

Hat anscheinend soweit geholfen dass Android Chrome die Seite wieder darstellt. IE funktioniert auch noch. iOS Safari auch. Damit ist das Problem zwar nicht gelöst, ich kann aber die Visu remote benutzen.

Lokal dann mal halt direkt auf den wiregate.

Nochmals Dank!

[Chris M.]

Habe ich gemacht, scheint am keep-alive zu hängen (siehe screenshot).

Du meinst das "connection: keep-alive"?

Das ist ganz normal und sagt quasi nichts über den Inhalt.
Der Antwort-Header sieht eher so aus:

HTTP/1.1 [B]200 OK [/B]
Transfer-Encoding: chunked 
Content-Type: text/plain 
Date: Wed, 28 May 2014 20:11:32 GMT 
Server: lighttpd/1.4.19

Dieser HTTP Response Code (vgl. Fett) wäre das spannende.

[koend]

Was ich genau meinte, weiß ich auch nicht mehr... :-)

Wenn ich den Debugger recht verstehe (siehe neuer Screenshot), schickt Firefox mehrmals die gleiche cgi-bin Abfrage: r?s=SESSION etc.

Die erste kommt zurück (grüner Status), die folgenden bleiben hängen (grauer Status): der Response header ist bei allen leer.

Wie gesagt: nicht kritisch, verwunderlich...

Gruß,

Koen

[Chris M.]

Ne, das ist völlig normales Verhalten, wenn auf dem Bus keine relevante Botschaft gekommen ist.

[koend]

So, gerade ist mir aufgefallen dass rechts oben ein Scrollbalken eingeblendet wird: aus irgendeinem Grund wird nicht die gesamte Höhe des Fensters genutzt. Im Screenshot nur 32px. Dieser Wert ist aber non-determinisitsch, da ich auch schon 30px und 48px gesehen habe.

Im IE hingegen wird die Höhe korrekt berechnet.

Gleiche Seite, direkt vom Wiregate liefert im Firefox die richtige Höhe (489px mit Debugger). (ja, ich sehe auch gerade dass beim Anpassen des update_rrd was schief gelaufen ist... da kümmere ich mich gleich mal drum).

Hilft das weiter?

[Chris M.]

Hilft das weiter?

Äh, leider nein.

Also: Wenn der gleiche Browser die Visu korrekt aus dem lokalen Netz anzeigt und falsch wenn's z.B. über ein VPN geht, dann ist die Verbindung zu verdächtigen.
Wenn nun in der Debug-Konsole bei allen angeforderten Daten (das "r" ist speziell, da läuft ja der COMET-Zauber) der Status passt (also z.B. 200), dann bleibt eigentlich nur noch ein Fehler im Cache. Und zwar im normalen Cache als auch im Offline-Cache (der ist getrennt zu löschen)

[koend]

Meister Chris, du bist ein Held! 3x Cache löschen war des Rätsels Lösung. Vielen Dank!

Hatte zwischendurch die Proxy-Einstellungen geändert. Funktionierende Einstellungen sehen jetzt so aus:

        ProxyRequests Off

        ProxyPass /cgi-bin http://wiregateZZZ.knet/cgi-bin
        ProxyPassReverse http://wiregateZZZ.knet/cgi-bin /cgi-bin

        ProxyPass /visu_svn http://wiregateZZZ.knet/visu_svn
        ProxyPassReverse http://wiregateZZZ.knet/visu_svn /visu_svn

Nochmals vielen Dank!

[koend]

Aus gegebenem Anlass (Wiregate endlich in ein separates VLAN geschoben) musste ich mir die Konfiguration noch einmal genauer anschauen und kam dabei einem Fehler auf die Schliche: Parameter von ProxyPassReverse waren verwechselt. Außerdem scheinen die SetEnvs nicht mehr nötig zu sein

So funktioniert es wieder:

# disable forward proxy
ProxyRequests Off

ProxyPreserveHost On

ProxyPass "/cgi-bin" "http://wiregate.knet/cgi-bin"
ProxyPassReverse "/cgi-bin" "http://wiregate.knet/cgi-bin"

ProxyPass "/visu_svn" "http://wiregate.knet/visu_svn"
ProxyPassReverse "/visu_svn" "http://wiregate.knet/visu_svn"
ProxyPassReverseCookiePath "/visu_svn" "http://wiregate.knet/visu_svn"
# <Location "/visu_svn">
# #SetOutputFilter proxy-html
# SetOutputFilter INFLATE;proxy-html;DEFLATE
# SetEnv force-proxy-request-1.0 1
# SetEnv proxy-nokeepalive 1
# </Location>