Forum OpenACS Q&A: Response to ns_returnredirect breaks with nsvhr and IE?

I believe the answer is that instead of calling ns_returnredirect, you just call util_ReturnMetaRefresh.

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.)

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

Also, here's another snippet showing how rubylane does the meta refresh only when needed (but ad_returnredirect is very similar)

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