Server-side caching

HCL Domino Domino Forum
1

We recently upgraded our Domino server to R6.01 CF1 from R5.10. Since the upgrade we are experiencing an intermittent problem on a database accessed via browser in which a user cannot use the back button on the browser to return to the search results after opening one of the documents returned in the search.

Some details.

  1. I have been able to reproduce the problem in Mozilla Firebird 0.6, but not Internet Explorer 5.5 or Netscape 7.0 or in Opera 7.11. However I have had users report this problem who were using Internet Exploror 5.5 (Error received from IE users - Warning: Page expired).

  2. SOMETIMES when I search the database I get the following message from my Mozilla Firebird client upon clicking the back button from a document I opened from the seach results.

“The page you are trying to view contains POSTDATA that has expired from cache. If you resend the data, any action the form carried out (such as a search or online purchase will be repeated). To resend data click OK. Otherwise click Cancel.”

If I click OK, I can return to the search results and open another document. However, I cannot use the back button to close the second document and return to the search results.

  1. There is nothing in the database design that controls caching in this database.

Any ideas what’s causing this? Thanks for your help! Have a great day!

2

Subject: Server-side caching

The “real” fix would be to make sure that everything that should remain more-or-less static should be obtained via GET rather than POST if at all possible. It makes for an incredibly ugly URL, but it’s the way things are supposed to be done on the web. If the search query is being generated by a search form, then generate the search URL in the browser if it’s at all practical, and use the GET method. Of course, there are hard limits to the length of URLs (whether they be imposed by platform limitations or hackproofing software), so one does occasionally require a POST. Again, JS can control the “flip” between the two methods – and will allow a default POST if the client does not hav JS enabled.

3

Subject: RE: Server-side caching

Stan,

Thank you for your response.

Sorry to be so stupid (I just can’t help it - but I’m getting better :slight_smile: - especially after getting a lot of answers in these forums), but I am not sure how to implement your advice. This search is just executed by saving and closing a form with a $$Return field. So it is Domino that determines if a GET or POST is issued. How does Domino determine this? (If this is a case that I should RTFM - please direct me, since I obviously can’t seem to find it.)

FYI - Formula for the $$Return field is the following (brackets have been replaced by braces).

DBName:=@Subset(@DbName;-1);

“{{/”+DBName+“/WebSearchPolicy/?SearchView&Query=” + SearchFor + “&Count=0&Start=1” + “}}”

So I guess what you are saying is to “roll my own” and totally redesign the search mechanism. I just don’t understand why this would stop working since the design hasn’t changed since 2001. Reports of this problem have only surfaced since we upgraded the server software to R 6.0.1 CF 1 and applied the MSBlast patch.

Do you think a web site rule to always cache the page would help?

Thanks again for your help (and the help you have unknowingly provided me in the past through your other posts). Have a great day and an even better weekend (unless that’s just too much trouble of course)!

4

Subject: RE: Server-side caching

Having a “better weekend” is almost always more trouble than it’s worth. I’ll just have a “fair and incident-free” weekend, if you don’t mind – it’s a lot easier to make the arrangements.

Well, the $$Return IS generating a GET request, but the redirect is at the server rather than at the browser. That means that the last thing the browser was doing (as far as it is concerned) was POSTing a form to the server. (It’s the double square brackets doing the internal redirect.)

There are two ways to fix this. The easy way is to make the double square brackets into singles. This sends a redirect message back to the browser instead of the search results, then the browser requests the search results on its own. That will allow a “back” action to work, but it does mean an extra request-reply.

The other alternative is to use some JavaScript to generate the GET in the browser and avoid submitting the form at all. This avoids two request-reply pairs, so it is the fastest alternative. The problem is that it won’t work if the client has JavaScript turned off.

So why not do both? Create a JS function something like this:

function goToSearch() {

var loc = window.location.href;

var stub = loc.substring(0,loc.indexOf(‘.nsf’) + 4);

var searchFor = document.forms[0].SearchFor.value;

loc = stub + ‘WebSearchPolicy?SearchView&Query=’+ escape(searchFor) + ‘&Count=0&Start=1’;

window.location.replace(loc);

return false;

}

and in the onsubmit of the form, put:

return goToSearch()

If the client has JavaScript enabled, the browser will generate the query directly, making it a GET. If JS is not enabled, the form will be submitted, then the server sends the redirect message to the browser, which requests the search, again via GET.

5

Subject: RE: Server-side caching

Stan,

I hope your weekend was as fair and incident-free as you were hoping it would be!

Thank you very much for explaining this to a dinosaur like me. I have made the quick and easy change (used single brackets) and it seems to have fixed the problem. This will hold people until I can get the JavaScript method you suggested implemented (after I finish writing this).

You are the man! (I meant that more in the cheering way and not so much in a blaxploitation film way.) :slight_smile:

Thanks again. Have a quiet, yet enjoyable day!