Hi. I've got a server (apache 1.3.20 + modssl-2.8.4 + mod_perl-1.2.26)
running on a linux machine. I've had problems with IE and ssl. I've got
the magic lines in my conf file (inside my ssl virtual host
container):
SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
which should force apache/mod_ssl to use http/1.0 and allow unclean
shutdowns for the ssl connection. except it doesn't. On closer
inspection, my access log files contained the following (the first
request is ssl, the second is plaintext):
192.168.1.120 - - [22/Jan/2002:15:54:15 -0800] "GET /library/library.css
HTTP/1.1" 200 3327
<---snip---->
192.168.1.120 - - [22/Jan/2002:16:22:06 -0800] "GET /library/library.css
HTTP/1.1" 304 - "http://devotchka.sonicopia.com:12345/maestro/home"
"Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; T312461)"
My log format is correct, but just to make sure, i added the same log
format entry into the ssl virtual host. still nothing.
next, i wrote an apache module to dump my environment. accessing it from
ssl shows that mod_perl is definitely aware of the HTTP_USER_AGENT env
variable. but apache seems to be ignoring it, which causes the above
regex not to work, which causes IE to fail, which leaves my boss very
angry.
I tried this setup with the most current versions of openssl + apache,
and the result was the same. i tried searching on google, but i just get
pages and pages of RTFM's pointing to the above solution. my questions
are as follows:
1) is this a mod_ssl bug or an apache bug?
2) has anyone else noted this behavior?
3) how can i set the above values unconditionally? SetEnv needs a
name/value pair, and it doesn't seem like any of these are variable
names or values. the app i'm working on is IE specific anyway, so i
don't need to worry about non-MS browsers.
thanks...
-jon
--
jon@divisionbyzero.com || www.divisionbyzero.com
gpg key: www.divisionbyzero.com/pubkey.asc
think i have a virus? www.divisionbyzero.com/pgp.html
"You are in a twisty little maze of Sendmail rules, all confusing."
running on a linux machine. I've had problems with IE and ssl. I've got
the magic lines in my conf file (inside my ssl virtual host
container):
SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
which should force apache/mod_ssl to use http/1.0 and allow unclean
shutdowns for the ssl connection. except it doesn't. On closer
inspection, my access log files contained the following (the first
request is ssl, the second is plaintext):
192.168.1.120 - - [22/Jan/2002:15:54:15 -0800] "GET /library/library.css
HTTP/1.1" 200 3327
<---snip---->
192.168.1.120 - - [22/Jan/2002:16:22:06 -0800] "GET /library/library.css
HTTP/1.1" 304 - "http://devotchka.sonicopia.com:12345/maestro/home"
"Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; T312461)"
My log format is correct, but just to make sure, i added the same log
format entry into the ssl virtual host. still nothing.
next, i wrote an apache module to dump my environment. accessing it from
ssl shows that mod_perl is definitely aware of the HTTP_USER_AGENT env
variable. but apache seems to be ignoring it, which causes the above
regex not to work, which causes IE to fail, which leaves my boss very
angry.
I tried this setup with the most current versions of openssl + apache,
and the result was the same. i tried searching on google, but i just get
pages and pages of RTFM's pointing to the above solution. my questions
are as follows:
1) is this a mod_ssl bug or an apache bug?
2) has anyone else noted this behavior?
3) how can i set the above values unconditionally? SetEnv needs a
name/value pair, and it doesn't seem like any of these are variable
names or values. the app i'm working on is IE specific anyway, so i
don't need to worry about non-MS browsers.
thanks...
-jon
--
jon@divisionbyzero.com || www.divisionbyzero.com
gpg key: www.divisionbyzero.com/pubkey.asc
think i have a virus? www.divisionbyzero.com/pgp.html
"You are in a twisty little maze of Sendmail rules, all confusing."
Attached Files:
-
signature.asc (0.23 KB)