nicht angemeldet
Hi Sönke,
... 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 ...
Sofern Du Dich nicht auf ein spezielles Verhalten
des IE beziehst
genau das tue ich. Probiere es selbst aus - dafür gibt
es ja das Ding hier:
http://www.schroepl.net/projekte/msie/
Wenn meine Vermutung zutrifft, würde Mozilla
exakt dasselbe Problem haben. (Opera 6 übrigens
nicht!)
Warum? Was ist Deine Vermutung?
Ein caching proxy.
Weder M$IE noch Mozilla interpretieren "Content-
Encoding: gzip", wenn sie nicht selbst danach gefragt
haben. :-(
Ich persönlich halte Dateien mit Content-Encoding,
egal welcher Art, für grundsätzlich Cache/Proxy-
geeignet.
Ich auch - es müssen sich nur alle Teilnehmer an die
Spielregeln halten. Und die sind sehr kompliziert ...
deshalb versuche ich ja gerade, sie aufzuschreiben.
Es werden schließlich bei jeder Anfrage die gleichen
Daten geliefert, lediglich die "Transportform" ist
eine andere.
Das sehe ich anders. Ich fasse das Content-Encoding
als Teil der Daten auf, nicht als Transportverpackung.
Die Browser sehen das übrigens genauso (Cache-Inhalte
sind ggf. gzip-komprimiert).
Insofern sollte ein zwischengeschalteter Cache
entweder diese Daten entsprechend auspacken,
zwischenspeichern und selbst zur Verfügung stellen
Das darf er nicht, weil er die Negotiation nicht selbst
durchführen kann.
oder aber, wenn er die Content-Encoding-Methode
nicht kennt, den Inhalt nicht zwischenspeichern und
nur durchreichen.
Sie nur zu kennen reicht nicht aus. Er ist einfach
nicht befugt, dem Server die Entscheidung abzunehmen
- vor allem dann nicht, wenn er nicht weiß, was er tut.
Schlimmer noch: Der Proxy weiß gar nicht, daß der
Server das Ergebnis einer Negotiation gesendet hat!
Da geht das Problem nämlich schon mal los ...
Cache-Mechnismen brauchen da garnicht zum Zuge
kommen, anders als beispielsweise bei Accept/
Content-Language-basierten Sachen.
Ich sehe zwischen beiden Problemen keinen Unterschied
- weil der Proxy auch keinen erkennen kann.
"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?
Weil erstens der Browser manchmal lügt und zweitens
der Server seine eigenen Vorstellungen davon hat,
was komprimiert auszuliefern Sinn macht und was nicht.
Der Server kann darauf reagieren (mod_gzip-Konfigura-
tion), und zwar sehr individuell.
Der Proxy kann das nicht begreifen, weil er die Kon-
figuration dieses speziellen Webservers nicht kennt.
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.
Nein - es reicht völlig, gzip-kodierte Daten _mit_
Content-Encoding auszuliefern, um sowohl Mozilla als
auch M$IE zu überfordern.
Oder gzip-kodierte Daten, die er selbst (aufgrund
der entsprechenden Browseranfrage) nochmal un-
nö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.
Ich versichere Dir, daß das Problem _nicht_ in einem
Fehler des Proxy-Servers zu suchen ist. Alle machen
alles richtig, so gut sie können - aber in der Summe
aller Aktionen kommen unbrauchbare Daten heraus.
Das ist die Situation - und das ist ein echtes Problem.
Mein Artikel versucht, zu beschreiben, wer was wie
anders machen müßte, damit es funktioniert - auch
mod_gzip müßte etwas mehr tun als bisher.
Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael