httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Compression via content negotiation
Date Tue, 01 Dec 1998 21:39:36 GMT

Need to be careful about assuming that even the
latest versions of 'the big 2' browsers support 'Accept-Encoding'.

Have to remember that the only reason gzip has been
dropped into these browsers was to support the new
.PNG graphics format. Even if 'gunzip' is 'in' the browser
it doesn't mean it's ready to decode, display ANY kind
of document. It is impossible to get a firm commitment
from anyone at NETSCAPE(tm) or MICROSOFT(tm) 
with regards to 'full compliance' for 'Accept-Encoding'
and/or 'Transfer-Encoding' (TE). They focused on .PNG,
not HTML. Search the WEBSITES for the major browsers.
The silence on this is deafening.

Also... with regards to having documents around that
are ONLY 'gzipped'... what about search engines? How
will they ever know what's there if they don't support
the encode type?  As far as I know... Content-Encoding
scheme, if applied to HTML files, requires the ENTIRE
DOCUMENT to be compressed. You can't tell it to
'leave the meta-tags alone' so document can still be
'found' by search engines. This sort of negates using
it at all. What good are WEB DOCUMENTS that 
can't be SEARCHED? Might as well be on an intranet
where you can do whatever you want, anyway.

For that matter... what will a FIREWALL do if it gets
a completely GZIPPED HTML document? Won't be
able to identify it and users will be wondering 'what's wrong?'.

When you consider that the 'intent' of 'Content-Encoding'
was never meant to be applied to HTML documents you
realize that there are a lot more issues to consider than
simply 'Is there a GZIPPED version of this puppy on the server?'.

View raw message