httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Compression via content negotiation
Date Wed, 02 Dec 1998 22:02:07 GMT

> No, he was suggesting sending it when the user agent sends Accept-Encoding.
>  A search engine is a user agent, so it isn't going to ask for an
>  encoding that it can't understand.  The breakage is on shared caches
>  and dumb browsers, not on search engines.
>  ....Roy Fielding

Roger that. I'm not sure what Paul A. really wants to change, then.

BTW: A lot of the discussin is in a sense, academic. If ANYONE wants
to compress their HTML documents independent of SERVER SIDE
support or CLIENT BROWSER COMPATIBILITY there is at least one
product I know of that ALREADY DOES THIS quite well. Average
compression is 60-70% on ANY HETML document including DHTML,
XML and JAVA APPLETS. ( Yes.. it even compresses JAVA(tm)! ).

Basically... it puts all the decision making on the CLIENT SIDE
so there is absolutely NO PERFORMANCE impact on the server.

It also does the following...

1. Allows META TAGS, TITLE, DESCRIPTION headers, etc. to be
   RETAINED and UNCOMPRESSED so the search engine issues
   with regards to static content-encoding are a moot point. You do
   NOT need to have 2 copies of the document which makes ISP's
   happy. They are the ones who are cherry about disk space.

2. Possible firewall issues are also of no concern since the most
    relevant parts of the HTML document can remain uncompressed.

3. Decision making about whether or not there is an 'uncompressed'
    version of the document available is taken care of on the CLIENT
    SIDE and is completely the responsibilty of the authors of the
    document. The SERVER is not asked to make ANY decisions.
    This is the way any scheme like this ought to be implemented.
    The SERVER is not ( nor should it be ) omniscient.

4.  Does a lot of  'neat' things OTHER than great compression on HTML.
     It has the ability to ENCODE an EXECUTABLE code fragment
     in an HTML document which EXECUTES when it hits the browser.
     It can do things that JAVA can't. This part of the product is called

The name of the product is HyperSpace(tm) CHTML(tm) and is available

It has been written up in the HIGH-TECH section of the DENVER POST
and will be a featured article in next week's BOARDWATCH magazine.
Since the product was released their server has been getting over
1,000 hits per day and climbing.

It's HERE NOW, IT WORKS, and is a viable solution for just about ALL
of the 'compression' discussions taking place at this time in BOTH
the MS and NETSCAPE arenas.

Supporting any 'specific' COMPRESSION scheme from within the server
itself is actually a lot like saying that APACHE should internally support
the ADOBE .PDF format. It's used, it's popular, but why should the
SERVER care? It could go away tomorrow when something 'better' comes
along. From the viewpoint of any true HTTPD SERVER... Some things are
probably best left to external modules and 3rd party software.

View raw message