Komischer Output
sushi
- sonstiges
hallo.
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Ÿ: ¹"'€rìß(¢(wÜIÊ ‹Ý³g ìš-Înÿº×“ßnß.ÉõÇw-gÄé¹îÝÑ™ëÎngŇ-}o@n%åŠi&8M\wþÞ™þøÃ8Öibü†æW3ØÀôf~yn&ŽÈïtMoÉ2íÎWc·øŽ‚ ã+"!™8J?$ bíýüÁÄÑðU»üR‰%,'N¿ï\*¸ '¥Yßo>)hJ8MqJÊ®‚Ö9ß@p \OœÊ“Cò͘†„|É…>Ù6¬xwH.xLÝok\_Áýü¡²ª»µoôTˆ7ä) '…ÿM®DI[1Íu,d¥¶©XÃ'rruüçirÂIåýßh\*8ôCØh‹µÎzð%gë‰Sêè,ØìF ªQpB‚˜Jzrq³è½ysü¶7hÛ5;ë\_ç~Â0,ÖºZË“VÔsgTƒ³ãÓÐó½ü×¾¾õÞŒ<ïo€÷Žé!ʳ%³k×ÓìÅ#wÂìîg¿ˆ¿Ëx\_û(С÷'ò(§l3¤Óƒ,ŠuïZ‰!ÓB2Lü@dÒˆíYÍ€Ð?“
±x&†WýO UÉçzúN¤¬ä5:U„{#¹ü!G»ÅuÜv-b2™Lº¹ £[¥·/ÂâGüH„œ8/Îí…i‹Ü¡g/‡˜ÜÆáééññpèüu9~ýz84Ÿi9.ÅQß)ÔO€ü$ CÆ£‰óÒ±c•ÑÀŽqªÅYÒ>Þ³PLjçýlmÔÒÞÃ-óæóÙÌ€o“pŸªÔÄátíLÇ´RD¹H‹ ?°4"XrêÒƒehE³~Ä-›…_ay|>Ú2 KÈĹ-ü5†o:vé“àZu1k€;öëb9v}+ê6EÑNQSÖ³ˆ¦>qþΨÄè9Ó÷µ˜ŠY²naµµAsKhvšÛ«%Áƽü×üC""±ì‚ׄÁ{»‹Cå×SÛóß&¬'!†ËZ‹´êq<œ¶w|õßœ-V2Q'ås€ˆ-‰Óv9ðuËý#oãý'X²"‹^íâPn? ð^$UUB5í*ò#›Þ0Î×"Á,ù$ä 8ל)ä1O‰)ú€Ú½"Ä×#Òeûv䎟æoiß3=à¾ÊNš¤4å·Eâ&üIÎC2 Àø²ØÀp*ŠsòRü«œGøü˜ïŠÕ~#½rhîšÈ¸-ÂÕÄ¡ìðÆ&Q[½áQe{ìæÌ(üäÔW¨€iMÐ0»›ãפ-o×RD'¦)¾P™¤A [-€aÜvO=³ ŽüÜqÒü¬(çÕ'[ëù 4ÄšÐ'¥H¢>ë.·ø~4$¥•<ðÑØÍ,SöUSï©j:5 c¨ÈޤYE¹Žø6²á©Ã0oð¹a€Ûi½µY^D¨@«;9¿ ÁËp¶Þ0è¦HÀ¾›]ûÈ•nÛµ°o{
˜cÅß͘ʂвç“ß#W1Šª-¨l25ߤ-©}¶TãÍPµ"\¹H%VиaÒ£Åw]:5<.)½ghn»„®tŽj +÷Øu''Ƕz§&‡…6;;i« KV¤)&ÿ½á½ÿ'üöË»Ào
was geht??
gruss s.
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. Er hat offensichtlich eine komprimierte Version jener Seite angefordert (was gut ist), war dann aber nicht in der Lage, diese komprimierte Seite auszupacken (was schlecht ist).
Wenn's öfters auftritt, solltest Du Dir ein Update besorgen (beim IE wegen der Sicherheitslöcher eh anzuraten, siehe http://www.heise.de/ct/browsercheck/e5demo.shtml) oder auf einen anderen Browser wie zum Beispiel http://mozilla.org umsteigen.
Gruß,
soenk.e
Hallo Sönke,
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??
ich warte schon seit Wochen auf diesen Thread. ;-)
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.
(was schlecht ist).
Was zumindest zu einem interessanten Widerspruch zweier
Aussagen führt.
Wenn's öfters auftritt, solltest Du Dir ein Update
besorgen
Halt, Kutscher! Machen wir doch erst mal Ursachenforschung.
Deshalb an sushi folgende Fragen:
1. Verwendet Dein Internet-Explorer HTTP/1.0 oder 1.1?
2. Sendet er einen "Accept-Encoding: gzip"-Header?
(http://www.schroepl.net/projekte/msie/)
3. Hast Du in Deinen Internet-Optionen einen Proxy-
Server eingetragen?
4. Passiert dies bei mehreren unterschiedlichen
Internet-Providern oder nur bei einem bestimmten?
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!)
Ich habe das im Büro schon mal reproduzieren können.
Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael
P.S.: Lesetip:
http://www.schroepl.net/projekte/mod_gzip/cache.htm
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
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
Cache-Mechnismen brauchen da garnicht zum Zuge
kommen, anders als beispielsweise bei Accept/
Content-Language-basierten Sachen.
Ich sehe zwischen beiden Problemen keinen Unterschied
"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