Forum OpenACS Q&A: IE5 post/get issues redux...

Posted by MaineBob OConnor on

Back in Mid October Jonathan Ellis started this thread:

ns_returnredirect breaks with nsvhr and IE? (1)

He states the problem:

    ...but IE abruptly stopped honoring ns_returnredirects, complaining, "The page cannot be displayed." I upgraded my nsvhr patches to Jerry's v.6 but it is still happening...

Later in the thread, Johnathan offers patch 77 which "provides ad_returnredirect from ACS 3.4 and up. Save in tcl lib dir." Ok, this sorta solves the problem for returnredirect but it does not address the problem for:

  • The OLD: ReturnHeaders ns_write "...
  • The NEW: ns_return 200 text/html $page_content

For example, bboard in OACS 3.2.4 uses <form... and ReturnHeaders in the progression:

  • q-and-a-post-new.tcl - <form... button
  • confirm.tcl - <form... button
  • insert-msg.tcl

No returnredirect is used in this process of posting. I have customized bboard to use the newer
ns_return 200 text/html $page_content.

In both cases IE fails with big posts and NS does not. I used a test with a body of 18000 bytes and larger. the failure is "Request Error Missing form data..." and sometimes a partial page.

The above is using: AOLserver/3.3.1+ad13 with Jerry Asher's virtual hosting changes.

My users are complaining because we use forms to allow verbose postings (and not just bboard) AND it is NOT a solution to tell 'em to use Netscape... Only one of my users has upgraded!

Solutions? Is this a problem with newer versions of AOL server. Are there other patches I may be missing. Is this only a problem with Jerry's Virtual hosting?



Posted by Jerry Asher on

You're right, telling them just to Netscape is not a solution at all.  While I lots of reason to believe this is an IE bug, I just don't have the knowledge or resources to determine what exactly is happening.  Your best bet is to use Apache or SQUID for reverse proxying instead of nsvhr.

(By the way, here is a Microsoft bug report on another IE bug that has been blamed on nsvhr, but isn't an nsvhr problem);EN-US;q175318