nicht angemeldet
so sieht es in meinem browser ie5 aus,
wenn ich folgenden link lade.
http://selfhtml.teamone.de/javascript/index.htm
‹`MÚ;index.htm½XÛrÛ6}ïLÿe¦~©%Rrœ‹,iêXòÔ- ¹±OŸ:
was geht??
Dein Browser geht..nicht.
Das würde ich nicht so pauschal behaupten wollen.
Er hat offensichtlich eine komprimierte Version
jener Seite angefordert (was gut ist),
... und was bedeuten würde, daß er im Modus HTTP/1.1
zu kommunizieren versucht hat.
war dann aber nicht in der Lage, diese komprimierte
Seite auszupacken
... was bedeuten würde, daß er im Modus HTTP/1.0
zu kommunizieren versucht hat.
Wieso das? Accept-/Content-Encoding waren auch schon bei HTTP/1.0 definiert. In der HTTP/1.1-Definition steht sogar ausdrücklich drin, daß man HTTP/1.0-Clients besser mit gzip füttert, weil's bei denen in der Regel bekannt ist.
Sofern Du Dich nicht auf ein spezielles Verhalten des IE beziehst, ist diese Schlussfolgerung auf Protokollbasis (HTTP/1.1 > gzip-fähig, HTTP/1.0 > nicht gzip-fähig) falsch.
auf einen anderen Browser wie zum Beispiel
http://mozilla.org/ umsteigen.
Wenn meine Vermutung zutrifft, würde Mozilla exakt
dasselbe Problem haben. (Opera 6 übrigens nicht!)
Warum? Was ist Deine Vermutung?
P.S.: Lesetip:
http://www.schroepl.net/projekte/mod_gzip/cache.htm
Auch wenn's jetzt in's theoretische geht: Ich persönlich halte Dateien mit Content-Encoding, egal welcher Art, für grundsätzlich Cache/Proxy-geeignet. Es werden schließlich bei jeder Anfrage die gleichen Daten geliefert, lediglich die "Transportform" ist eine andere. Insofern sollte ein zwischengeschalteter Cache entweder diese Daten entsprechend auspacken, zwischenspeichern und selbst zur Verfügung stellen oder aber, wenn er die Content-Encoding-Methode nicht kennt, den Inhalt nicht zwischenspeichern und nur durchreichen.
Cache-Mechnismen brauchen da garnicht zum Zuge kommen, anders als beispielsweise bei Accept/Content-Language-basierten Sachen.
"Denn nur der HTTP-Server kann (aufgrund seiner Konfiguration mit entsprechenden Filter-Regeln) letzten Endes herausfinden, ob auch der zweite HTTP-Client komprimierte Daten als Antwort erhalten darf."
Wieso? Der Proxy bekommt doch als erstes die Anfrage vom Browser zu sehen, somit ist er auch der erste, der weiß, ob der Browser gzip & Co. versteht. Warum sollte dazu nur der Server in der Lage sein?
Kurzum: So gesehen könnten wir es hier auch mit einem defekten Proxy zu tun haben, der auf eine Anfrage eine falsche Antwort liefert: vielleicht gzip-kodierte Daten aus einer vorigen Anfrage, aber ohne Content-Encoding. Oder gzip-kodierte Daten, die er selbst (aufgrund der entsprechenden Browseranfrage) nochmal unnötigerweise gzip-kodiert hat, weil das Content-Encoding-Feld nicht im Cache mitgespeichert wird und er somit über den wahren "Zustand" seiner Daten nicht Bescheid wusste.
Gruß,
soenk.e