Sie schreiben, die Seiten wären in MSIE und NN nach wie vor lesbar. D.h. sie verwenden entweder eine Komprimierung durch Optimierung des HTML-Codes (Leerzeichen, etc. raus), was IMHO auf gut geschriebenen Webseiten (z.B. mit WML oder HTML Tidy generierten) kaum noch möglich ist, oder sie verwenden eine Komprimierung ala gzip oder zlib (was eher den Komprimierungsaussagen entspricht) und geben das als Transfer-Encoding-Header in der HTTP-Antwort an. Transfer-Encoding funktioniert aber nur mit HTTP/1.1 und auch nur, wenn der Browser das unterstützt, was gegen ihre Aussage bzgl. des Supports in MSIE und NN spricht: Insbesondere die Windows-Varianten von NN 3.x, 4.x und MSIE 3.x, 4.x unterstützen AFAIK z.B. kein gzip-Encoding (egal, ob Content- oder Transfer-Encoding) sondern verweisen gegzippte Dateien an eine extern Applikation wie WinZip.

Beide Varianten sind übrigens alte Hüte: Es gibt sowohl schon lange Software die HTML optimiert wie auch Module, die on-the-fly HTML gzippen und der Antwort einen Transfer-Encoding-Header verpassen (z.B. mod_gzip für den Apache).

Meine als gegzipptes HTML abgespeicherten Webseiten sind übrigens auch ohne jede zusätzliche Server-Last im NN unter Unix lesbar. :-)

Und außerdem: Komprimierung von HTML ist schön und gut, nur verursachen im Web leider JPEGs und GIFs den meisten Traffic. Interessant wird das erst wieder bei XML, denn XML-Dokumenten werden meist sehr feine Tag-Bäume mit meist deskriptiven Tag-Name aufgebaut, bei denen Kompression wirklich Not tut. Aber bis XML-Dateien den meisten Traffic ausmachen, dauert es noch ein bißchen. Falls es überhaupt dazu kommt. ;-/

Ich habe letzthin im Rahmen eines Quality-of-Service-Seminars einen Vortrag über Kompression zwischen Proxy und Low-Bandwidth-Clients gehalten. Da sind auch noch einige Infos zu Kompression im Web allgemein drin. Den Vortrag und Links gibt es unter http://w5.cs.uni-sb.de/~abe/QoS/. (Allerdings ist der Server momentan nach einem Angriff vom Netz, er sollte aber die Tage wieder ans Netz gehen.)

Echt schade, dass sie nicht schreiben, wie sie komprimieren, nicht mal einen Hinweis drauf hats.

maol
--
/server irc.lugs.ch /join #symlink

Auf der CeBIT habe ich Syntion einen Besuch abgestattet: Sie bedauern, daß ihre erste Pressemeldung zu solchen Spekulationen geführt hat, deswegen hier kurz ein paar Infos zu mod_ssc:

• mod_ssc macht von außen gesehen genau das gleiche wie mod_gzip: Komprimierung von (vorallem) dynamischen Webseiten per deflate- bzw. gzip-Algorithen, versehen mit passenden HTTP-Transfer-Encoding-Headern.
• Das Interessante und Neue an mod_ssc ist die geringe zusätzliche Server-Belastung durch die Komprimierung. Laut einem Test von Syntion erhöht mod_gzip die Server-Last um etwa 75%, während mod_ssc die Last um gerade mal um 20% erhöht. Somit können mehr Anfragen pro Zeiteinheit bei gleicher Last beantwortet werden. Die Meßwerte hierzu habe ich allerdings leider nicht mehr im Kopf.
• mod_ssc ist vorallem für die Komprimierung von dynamischen Webseiten gedacht wie z.B. JSP und PHP.
  Leider wird jedoch mod_perl nicht unterstützt.
• Details darüber, warum mod_ssc so fix ist, will Syntion erst zum Start der Beta-Test-Phase (2. Mai 2001) bekannt geben. Beta-Tester bekommen nach Abschluß der Testphase eine Lizenz im Wert von 349 Euro geschenkt. Anmelden zum Beta-Test kann man sich unter http://ssc.syntion.com/.

BTW: Die Benchmarks von Syntion wurden mit dem Apache Benchmark Tool gemacht, sind also nicht unbedingt an den Haaren herbei gezogen.

P.S.: Nein, ich werde für dieses Posting nicht bezahlt. ;-)