Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <46F3F1D4.6050800@rowe-clan.net>
Date: Fri, 21 Sep 2007 11:31:16 -0500
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
User-Agent: Thunderbird 1.5.0.12 (X11/20070719)
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: OpenSSL compression (Windows)
References: <46EFECDC.5030701@rowe-clan.net>
 <46F032EB.6050703@bellatlantic.net> <46F038FF.5090104@rowe-clan.net>
 <46F3DDE9.8030404@bellatlantic.net>
In-Reply-To: <46F3DDE9.8030404@bellatlantic.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Tom Donovan wrote:
>
> A case can be made for not enabling OpenSSL compression on Windows.
> 
> If both parties to an SSL connection support compression, it is used for
> everything on the connection without regard to whether the content is
> compressible.
> 
> Already-compressed data; like .jpg, .gif, .png, .zip, .tgz, .jar, and
> any content filtered by mod_deflate are re-compressed.  This uses
> non-trivial CPU cycles for no (or slightly negative) benefit.
> 
> Testing with some current browsers (FireFox 2.0.0.7, IE 6.0.2800.1106,
> IE 7.0.6000.16512, Opera 9.23) shows that none support TLS compression,
> even though they all have gzip capability - so there is not currently
> any issue with browser requests.

Agreed, I think we need to get a handle on this within mod_ssl itself.

> The problem is when Apache is configured to proxy via https to another
> Apache server.  If both servers have OpenSSL compression enabled,
> everything will be compressed (or re-compressed).  If both OpenSSL
> libraries support compression, there is no apparent way to override this
> behavior.  Previously, deleting zlib1.dll would accomplish this - but
> now deleting zlib1.dll will disable mod_deflate as well.

Not on win32, all the binaries I've created are --enable-zlib, never
--enable-zlib-dynamic.  On 0.9.7 this was all irrelevant of course.

> Since mod_deflate can be tailored to compress appropriate content per
> request, the need to have compression at the connection level seems to
> be an unusual one.  Perhaps those few folks who do want this could
> rebuild OpenSSL with compression enabled rather than shipping OpenSSL
> with it enabled.

Keep in mind w.r.t. the win32 distribution, we need it enabled to
support compression of ajp streams, ftp data streams etc.

You are right about missing the context of compressibility, it would be
very nice if after packing up 64k and realizing little or no benefit,
if openssl would back off and decide to ship off the contents without
compression.  Because the feature is


I agree for https that mod_deflate works out better than built in
compression, so perhaps on a protocol level, beyond SSL Enable, we
need some 'SSL Enable nodeflate' sort of choice that can be dropped
into an https vhost, leaving it enabled, for example on an FTP Implicit
SSL vhost.

Bill