Here's the fix we use. What we found is that if a redirect follows a POST,
then MSIE will ignore the arguments present on the redirect.
JIm
proc rl_returnredirect {location} {
global __did_ns_return rlfont
global __trace_endtime
if {[info exists __did_ns_return]} {
rl_log error ignoring 2nd ns_returnredirect in [ns_conn url]
return
} else {
set __trace_endtime [ns_time]
__rl_writeallcookies
# This is a huge hack - MSIE 5 doesn't correctly handle a redirect after
# a post; they don't send any arguments that came with the redirect
if {[string first msie [string tolower [ns_set iget [ns_conn headers]
user-agent]]] = 0 [string compare [string tolower [ns_conn method]] post] == 0
[string first ? $location] = 0} {
ns_return 200 text/html htmlheadmeta http-equiv=\Refresh\ Content=\0;
URL=$location\/headbodyPlease wait. If this does not automatically refresh, a
href=\$location\Click here to continue/a/font/body/html
} else {
aol_ns_returnredirect $location
}
set __did_ns_return 1
}
}
# NOTE: next rename fails when file is sourced, 2nd rename fails
# on boot; this is correct
catch {rename ns_returnredirect aol_ns_returnredirect}
catch {rename ns_returnredirect {}}
rename rl_returnredirect ns_returnredirect
Hi AOLserver folks,
we're seeing a AOLserver problem in production on AOL.COM. Unfortunately,=20
they're running a very outdated version (2.3.3), just wanted to make sure yo=
u=20
guys fixed this problem in later releases, here it is.
Magic Carpet is POSTing to www.aol.com, which in turn issues a redirect. Thi=
s=20
causes IE5.5 and IE6 to display a page not found error in certain=20
circumstances. Weird circumstances. Turns out it relates to the number of=20
packets sent by the browser:
We have following events sequence:
=A0=A0=A0 1) IE sends first request TCP packet to aol.com server with HTTP h=
eader:
=A0=A0=A0 =A0 =A0=A0=A0 POST /index.adp HTTP/1.0
=A0=A0=A0 =A0=A0=A0 =A0 ..=A0 =A0=A0=A0=20
=A0=A0=A0 =A0=A0=A0 =A0Content-Length: 393
=A0=A0=A0 =A0=A0=A0 =A0
=A0=A0=A0 2) AOL.com server *immidiatelly* replies with HTTP 302 redirect
=A0=A0=A0 3) IE continues request and sends second TCP packet with HTTP body=
:
=A0=A0=A0 =A0=A0 =A0siteId=3DaolcomprodStagesiteState.
=A0=A0=A0 4) IE starts listening for reply from AOL.com server
=A0=A0=A0 5) IE failed to recieve data from AOL.com server (because reply wa=
s=20
already sent on step 2)
=A0=A0=A0 and shows error page to user
So the AOL server bug=A0 is that redirect is done *before* recieving HTTP bo=
dy=20
for POST request. If you turn on a proxy for the web browser, the problem=20
goes away, because this way the packets come back in order.
Again, we're aware that AOLserver version 2.3.3 is outdated -- but can you=20
guys confirm the problem will go away if we update to a more recent release?=
=20
Any help apprechiated.
-- Mike
Mike Schilli
[EMAIL PROTECTED]
Magic Carpet Engineering
