But even if the address changes:
as far as SSL is concerned they connect successful, but the
Content-Type-header corruption looks like a bug in memory allocation. So
some special AOL behaviour might be responsible for running through parts
of mod_ssl code which are rarely used and might contain the bug.
By the way: is there a way to sniff the ssl communication and decode later
on with session cache enabled? The only tool I know is ssldump and that one
does not work with the cache enabled, because it doesn't remember the keys
for using when the session is resumed. That's the reason we some time had
to disable the cache (we wanted to debug another problem) and then noticed
that the AOL problem also went away.
At 11:59 25.09.01 , you wrote:
>On Tue, Sep 25, 2001 at 11:46:24AM +0200, Rainer Jung wrote:
> > Hi,
> >
> > we notice the following problem:
> >
> > HTTP-Header Content-Type gets corrupt in rare cases for AOL users, if we
> > enable shared memory ssl session cache.
> >
> > Setup: We have apache 1.3.14 with mod_ssl (I don't have the version at
> > hand). Behind we use tomcat 3.2.23 on the same system to respond to
> > JSP-requests. Betwenn apache and tomcat we use mod_jk with ajp13. We
> > noticed, that tomcat sometimes did not find the contents of the POST
> buffer
> > and found out, that already before parsing the Request to tomcat, the
> > Content-Type-Header of the request, which we can print out early in mod_jk
> > is corrupt. It contains a concatenation of the correct string
> > x-www-form-urlencoded with a part of the string "Content-Type" and then
> > again x-www-form-urlencoded.
> >
> > The problem only happened to users coming from AOL, but for diverse
> > browsers. But: is we disable the session cache (shm) the problems vanishes.
> >
> > Platform is Solaris 2.6. The site is high-volume and uses strong
> > encryption. The problem is not strictly User or Browser dependant, it
> > occurs kind of statistically but only for Clients coming from
> > AOL-IP-adresses and only if session cache is enabled. Apart from that
> > communication seems to work good.
> >
> > Any comments?
> >
>Strange - usually people run into problems when they don't have their session
>cache on :)
>Since this probably is AOL specific, perhaps it happens because they proxy
>their
>ssl connections. AFAIK they proxy outgoing connections (at least for HTTP) and
>you can't be sure that all requests from a user will be comming from the same
>proxy even over a short period of time. I don't know if this is the case, but
>raising your SSLLogLevel such that you can see wether it is session cache hits
>or misses and wether the ip adress changes.
>
>vh
>
>Mads Toftum
>--
>With a rubber duck, one's never alone.
> -- "The Hitchhiker's Guide to the Galaxy"
>______________________________________________________________________
>Apache Interface to OpenSSL (mod_ssl) www.modssl.org
>User Support Mailing List [EMAIL PROTECTED]
>Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
