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 "<html><head><meta http-equiv=\"Refresh\" Content=\"0;
URL=$location\"></head><body>Please 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=3DaolcomprodStage&siteState.....
> =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
>
