My customer has a series of mature customer-facing web application that heavily leverage the use of
Print “[/nondomain.tld/foo/bar]”
redirects. This works perfectly on the old R5 deployment, (running behind IIS 5/Win2K) but the new Domino 6 server (running behind IIS 6/Win2003) apparently has problems with all print statements done this way.
For instance, in some $$return formulae, a line such as
“[/” + computedURL + “]”
will fail on the 6 server. The correct address appears on the browser’s address line for a split second, and then the address line reverts to just the FQDN of the server. So, for instance,
http://nondomain.tld/foo.nsf/bar?OpenView
will get into the browser’s address bar, and immediately be replaced with
which loads the homepage. The identical code works perfectly in the R5 production environment.
I saw several suggestions about loading the page using the double brackets instead like
“[[/someurl]]”
and this works for many of the $$return functions.
However, under some circusmtances, this breaks badly. For instance, when an agent is called from the browser window using the ?OpenAgent URL command, the agent finds an existing document, parses the right URL, and then uses a print statement to load the document in the browser window. If single square brackets are used as in:
Print “[/” & computedURL & “]”
the correct computed URL appears in the address window for a split second, but then is immediately replaced by the FQDN of the server, and instead of opening the intended document, the user sees the homepage.
If double brackets are used, the browser loads the correct URL into the main browser window, but the Address Bar never changes (which I gather is what the double bracket was intended to do). But when the user Submits their changes, they get odd results. It would appear that the problem occurs at the simple javascript form.submit function, because the submit seems to be keying off the original URL loaded at the address bar rather than the URL that was redirected to the window by the agent.
So instead of receiving confirmation that their document has been saved (which it hasn’t), the system instead returns “Agent Done” to the browser window and fails to save the doc. This would seem logical if it were pulling the $$Return of the agent that was used to load the document.
The part that messes me up here is that this method works perfectly in R5 running under IIS 5. But breaks completely under ND6 running under IIS 6 with the 5.0 Websphere plugin.
Searching this forum and other resources, I found other ways to do redirects, such as
Print ||
This renders correctly in all the cases where we’ve tested it, but there are litterally thousands of places where the old method using single square brackets is being used in the code. Having to go through and rewrite all those occurrences seems a bit extreme to me (not to mention my customer), especially given the old method (using single brackets) is still supposedly supported according to the Lotus documentation and posts I’ve seen on this forum.
So, the question: What is the actual cause of this malfunction? The Domino Web engine? IIS 6 versus 5? Websphere filter? Sunspots? and is there another way to correct this that doesn’t involve revising thousands of lines of “mature” code that works perfectly fine in a 5 environment? Is there some configuration element that I’ve overlooked?
Any information on this will be very helpful and appreciated.
To anticipate a possible question: we have tried both the default iisWASPlugin_http.dll file that comes with 6.5.2 FP1 (which is what their parent co. has certified, they cannot upgrade to 6.5.4 at this time) and the latest version of the iisWASPlugin_http.dll filter downloaded from IBM’s support site. (The latter was applied to resolve the %20 issue, which was also seen during our testing. See the thread at http://www-10.lotus.com/ldd/nd6forum.nsf/55c38d716d632d9b8525689b005ba1c0/7df105cd156578e185256feb003e3c46?OpenDocument for details.)