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

• the problem is related to nsvhr. If I go directly to the site's port, bypassing the master server, it works fine
• ns_returnredirect by itself works fine. It is also okay with some forms of computation before the ns_returnredirect, but set_form_variables followed by ns_returnredirect gives this error
• I could find no ns_writes or ns_returns before the ns_returnredirect (I checked because I know ad_return_error likes to return code 500, which IE interprets with the same "page cannot be displayed" message.)

Alternatively, I've been seeing a bug in IE (and it's definitely a bug) that's not present in Mozilla, or Opera, or Konqueror, where really big POSTs (or something about certain POSTs) cause IE to retry the POST once, and then issue a GET on the damn thing.  It's truly bizarre.  Sadly, it does seem related to nsvhr when using the nsunix module, and it's one reason I want to migrate nsunix functionality from nsunix itself to some patches to nssock (I believe nssock has a workaround, the "graceful-closewait")

Do you have it backported, so I don't have to?  It's pretty straightforward, but it calls ad_conn, which is in another file and probably calls other stuff (what's wrong with ns_conn?) and if it's been done I don't want to reinvent the wheel.

As to ad_returnredirect, it looks like it is trying to solve the same problem as the ns_form patch.  (Does anyone know if the ad_returnredirect code is outdated in this case?)  When my form action page gets to the ad_returnredirect, the content type is "application/x-www-form-urlencoded", not "multipart/form-data."

I use that to try and pin down exactly what the browser and server are doing.  That's how I've picked up on the oddities where IE can retry a POST, without the posted data, and even turn a POST into a GET.

I don't have a solution right now.  Since IE has something like a gazillion market share, I obviously want to find solution and/or a work around.  I guess I hear you saying the meta refresh will work.  Ugly as that is, it's probably the way to go for now.

Alternatively, I have some strategies involving more development of nsunix: 1) merge nsunix with nssock, that is, let nssock "accept" connections on a unix domain socket and after they are accepted handle everything else in a standard nssock sort of way, and 2) implement the nssock graceful closewait in nsvhr and nsunix as needed.  I'd be happy to help you attempt either of these.  My recommendation, if it works, is to do the meta refresh.  I think it's ugly too, but scanning the forums at aD and OpenACS, there is a long history of folks using that technique due to IE returnredirect oddities.

if {$submitted} {
	source /path/to/page2
	return
}

The problem isn't (directly) related to the length of form var names, but it is related to the size of the form data submitted, so if I have 40 dynamically generated select boxes in my form, it makes a significant difference when I use a 10 character name for each box than when I use a 20 character name.  With the longer name, the max form elements I could have before seeing this problem was about half what it is now.

Jonathan, From your Sum up:

1 Make sure your form data is small enough

This doesn't work for me. When you have a big text box like this one for sending lengthy posts to forums or when our UBER IE5.5 users send longish letters to groups of our users.

3 implement the nssock graceful closewait in nsvhr and nsunix as needed, which would involve some AOLServer hacking

Not something I'm up to!

2 use meta-refresh instead of returnredirect

Ok, I'm left with door #2! So how do I use util_ReturnMetaRefresh as a replacement for ns_returnredirect ?

I find nothing in openacs.org/doc/...(and the proc search here is broken (500) so I used my own 3.2.4 /doc/ directory.

-Bob

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

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