Forum OpenACS Q&A: Response to ns_returnredirect breaks with nsvhr and IE?
Then the browser just gets back "standard html output", but instead of getting a server specified redirect, the page has a meta tag that redirects the browser. That appears to work well with IE.
By the way, while I definitely want to get this fixed, IE has well known problems with redirects and confusing POSTs and GETs and retrying when it shouldn't. It's hit a bunch of people, including AOL (the following quotes came from a conversation just last week on a similar problem that wasn't nsvhr induced.)
Also, here's another snippet showing how rubylane does the meta refresh only when needed (but ad_returnredirect is very similar)Hi AOLserver folks,we're seeing a AOLserver problem in production on AOL.COM. Unfortunately, they're running a very outdated version (2.3.3), just wanted to make sure you guys fixed this problem in later releases, here it is.
Magic Carpet is POSTing to www.aol.com, which in turn issues a redirect. This causes IE5.5 and IE6 to display a "page not found" error in certain circumstances. Weird circumstances. Turns out it relates to the number of packets sent by the browser:
We have following events sequence: 1) IE sends first request TCP packet to aol.com server with HTTP header: POST /index.adp HTTP/1.0 ...... Content-Length: 393 .... 2) AOL.com server *immidiatelly* replies with HTTP 302 redirect 3) IE continues request and sends second TCP packet with HTTP body: siteId=aolcomprodStage&siteState..... 4) IE starts listening for reply from AOL.com server 5) IE failed to recieve data from AOL.com server (because reply was already sent on step 2) and shows error page to user
So the AOL server bug is that redirect is done *before* recieving HTTP body for POST request. If you turn on a proxy for the web browser, the problem 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 guys confirm the problem will go away if we update to a more recent release? Any help apprechiated.
-- Mike
Mike Schilli mschilli1@aol.com Magic Carpet Engineering
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