Date: Wed, 13 Oct 1999 09:42:08 -0600 (MDT)
From: Marc Slemko <marcs@znep.com>
To: new-httpd@apache.org
Subject: Re: Apache 164 percent speed increase
In-Reply-To: <0.efd242d6.25356a71@aol.com>
Message-ID: <Pine.BSF.4.10.9910130908420.90981-100000@alive.znep.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

On Wed, 13 Oct 1999 TOKILEY@aol.com wrote:

> 
> In a message dated 99-10-13 00:02:46 EDT, you write:
> 
> >  > RCI's online compression servers work with ANY version of
> >  > ANY HTTP compliant server but when used in conjunction with
> >  > Apache there is a 164 ( ONE HUNDRED AND SIXTY FOUR ) percent
> >  > performance increase for Apache.
> >  
> >  Whatever.  There has already been far too much attention given to your...
> >  odd views about how compression should be done.  
> 
> Show me one other product in the world that is compressing Internet
> documents 'on the fly'... GZIP or anything else, based on actual sensing
> of the user agent capabilities and conforms to RFC standards. You
> won't find one. Everyone talks about doing it but talk is cheap.
> It is here now... we have already done it. We welcome any news about
> ANY other server product that can do the same so we can test against it.
> Competition is good. It's lonely being the 'only one in the world'.
> 
> >  Hmm, I notice that your solution still only works on IE running on Windows 
> 
> Sorry, wrong. Works on ALL platforms, ALL browsers... even LYNX.
> The benchmarking is for a true real-time online compression server.
> Runs on ANY Unix including Solais Sun Sparc Station. Works with ANY
> HTTP compliant server and any browser that supports Content-encoding.

Well, this must be a new thing that you have dreamed up then.  My comments
were in reference to your previous odd conecept of "C-HTML", which is 
still what your website gushes about.  In fact, some of your documents
on "HyperSpace" and "C-HTML" say what a bad idea it would be for the server
to be compressing things.

I can't comment much on your new solution, since you don't actually
have any real information about it available.  From what I can see,
you have just hacked up a proxy to be able to compress data on the
fly if the browser claims it can support it.  Not mind-boggling;
it isn't that difficulty to make Apache do that.  Unfortunately,
what looks to be your current implementation violates the HTTP/1.1
spec when it compresses the data, and will cause problems for any
scheme that attempts to provide integrity protectino for the headers
or body of a response.

I can say:

	- sure, compression is a potentially useful thing
	- sure, some browsers have some level of support for accepting
	  gzipped content.  Most (or all) Netscape versions, however, have
	  difficulty when certain components of a page are sent with a 
	  content encoding.
	- sure, a bit of work could be usefully done to make Apache support
	  it better.
	- the effects on a high traffic server are far from proven either
	  way; you have demonstrated no benchmarks that show anything 
	  other than a very low traffic server, plus a large amount of 
	  content is dynamic which means it can't easily be precompressed.
	- sure, in some situations, sending pre-compressed content is
	  better for the server since there is less on disk, less
	  in memory, and less to send to the network.  If you have
	  to have both versions though, for browsers that don't
	  support compression, the benefit to the server drops a
	  lot.
	- any attempt to create a magic bullet non-standard solution will
	  fail.