Hi,
we verified the problem in two ways: First we used mod_log_config to log
incoming Content-Type-Header (include "%{Content-Type}i" in your log
format) . Since this occurs late in the processing we additionally did
another thing: I patched mod_jk, the module passing over the request to
tomcat, to log the complete POST-Buffer at the moment the request is
processed. Both logfiles contained the same corruption.
I will produce a list of seen header values and of browser types but this
might take one or two days. Also since Eric Rescorla provided ssldump with
cache-awareness, we can now snoop the traffic to show the headers even
before they go to apache, so we can see, if they are already corrupt, at
the time they arrive.
I will give more information when available. What are your AOL related
problems?
Thanks so far
Rainer Jung
At 20:08 25.09.01 , you wrote:
>I think that this is important, as I am having specific issues with AOL
>customers getting errors. Can you tell
>me how to independently verify this problem? How do you find the
>Content-type header that the browser
>(AOL) receives when running SSL?
>
>Problem Browsers
>-------------
>Mozilla/4.0 (compatible; MSIE 5.0; Mac_PowerPC)
>Mozilla/4.0 (compatible; MSIE 5.0; AOL 6.0; Windows 98; Compaq; DigEx)
>Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 95; DigExt)
>
>Ok Browsers
>-------------
>Mozilla/4.0 (compatible; MSIE 4.01; AOL 6.0; Windows 98)
>Mozilla/4.0 (compatible; MSIE 5.0; CS 2000; Windows 98; DigExt)
>Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 4.0)
>Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)
>Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
>Mozilla/4.0 (compatible; MSIE 5.0; Windows 95; DigExt; TUCOWS)
>Mozilla/4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC)
>Mozilla/4.78 (Macintosh; U; PPC)
>Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)
>Mozilla/4.0 (compatible; MSIE 5.01; Windows NT)
>
>
>Nick
>
>*********** REPLY SEPARATOR ***********
>
>On 9/25/2001 at 12:21 PM Rainer Jung wrote:
>
> >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]
>
>
>
>______________________________________________________________________
>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]
