Re: HTTP serving compressed content (was Re: Perl "competitor" Curl raises $52M)

Date: Sat Mar 24 2001 - 18:09:53 PST

Andy Armstrong <> writes:
> Gordon Mohr wrote:
> [snip]
> > That suggests to me that either (1) it's so transparent it's easy
> > to miss; or (2) it doesn't save enough in bandwidth costs to be
> > worth the trouble.
> It's generally completely transparent and pretty effective. In our tests
> we've seen typical compression ratios of 6:1 on typical HTML content.
> Last time I checked something over 90% of browsers hitting our sites
> were able to handle GZIP compressed content, and those that can't
> degrade gracefully.

How do they degrade gracefully?

FWIW, I found recently that <script src="foo.js.gz"></script> doesn't
work in Netscape 4.76; despite correct content-type and
content-transfer-encoding headers, the stupid browser tries to execute
the script before decompressing it. I don't recall whether I tested
this with MSIE.

It seems libungif-generated GIFs could benefit from gzip
transfer-coding --- they'd be smaller than the corresponding LZWed
GIFs, and unlike PNGs, could be animated.

This archive was generated by hypermail 2b29 : Fri Apr 27 2001 - 23:14:52 PDT