httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 48713] Large subversion commits made to an SSL hosted repository error with SSL error "parse tlsext" or "bad decompression"
Date Tue, 09 Feb 2010 22:39:57 GMT

Gabe Martin-Dempesy <> changed:

           What    |Removed                     |Added
             Status|NEW                         |RESOLVED
                URL|                            |http://www.gossamer-threads
                   |                            |.com/lists/apache/dev/37563
                   |                            |3
         Resolution|                            |INVALID

--- Comment #1 from Gabe Martin-Dempesy <> 2010-02-09 14:39:51 UTC
Reading more documentation, it seems obvious, based on the timing and the
"tlsext" in the error message, that this is related to ServerNameIndication
introduced in Apache 2.2.12 (which is the starting version for most of the
reports I've seen).  Here's a few more notes with SNI in mind:

* Both the clients and the server's OpenSSL have SNI enabled, verified by
visiting an SNI test site via curl, linked against the same openssl as
* Putting the Subversion repository on its own dedicated IP/port slightly
improved the scenario; instead of erroring about 30 seconds into a large
commit, it now does so 5-6 minutes in.
* Completely removing the "NameVirtualHost" line from my
configuration (and appropriately adjusting the SSL VirtualHosts down to one
vhost per ip/port) has no effect
* Doing both of the above with TLSv1 removed from SSLProtocol still results in
the "bad decompression" error ~20 seconds into the commit.
* In all of the above, IE6 (which lacks SNI support) can access the subversion
repository URL without issue.
* Turning "SSLStrictSNIVHostCheck on" has no effect on subversion.  The error
still occurs as normal, and no warnings are displayed to the client or in
apache's logs.  IE6 gets a 403 and a warning in the log, though.

Based on this, it doesn't seem like the apache configuration is the issue here.

Also, after reading the thread from the http-dev mailing list archived at , it seems that the
root cause for this is an issue with SSL ticket / session id handling in the
client library.  The conclusion is that it will be fixed in the OpenSSL

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message