sushi: Komischer Output

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.

  1. 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

    1. 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

      1. 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

        1. 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