Post method, caching problem ...

zenith

Bizarre one, all help appreciated.

I've a niggly caching/search problem that I've been unable to come up with any solutions for. It's on www.recruitireland.net

<form action="jobsearch.asp" method="POST" id="form1" name="jobsearch"> arrives at jobsearch.asp happily and the search works.

You can burrow down another page (jobdetail.asp) and all is fine.

However, when you go back to jobsearch.asp using the back button you get a Warning: Page has Expired message. Which is by-design in the browser. Hit refresh, and the correct page displays as all the search session information is stored.

Is there any way of getting around this behaviour?

Does anybody have a suggestion as to how we can display a page to the people who use the back button WITHOUT having caching problems and WITHOUT using a GET?

dahamsta

Hi zenith,

Does anybody have a suggestion as to how we can display a page to the people who use the back button WITHOUT having caching problems and WITHOUT using a GET?

Use nocache headers/meta's on the FORM page? The page won't be cached, so the browser won't even try to load from there; and the page will reload from the server (& session) normally... ???

adam

zenith

Nope, all the possible stuff that can be done to prevent caching has been done: what we need is a way to prevent the default behaviour (if you go BACK to a POSTED page, it requires a manual refresh. We just want it to refresh itself).

The issue is that re-coding for GET is non-trivial, and we don't necessarily want people to be able to bookmark internal pages in the site in any case.

dahamsta

Nope, all the possible stuff that can be done to prevent caching has been done: what we need is a way to prevent the default behaviour (if you go BACK to a POSTED page, it requires a manual refresh. We just want it to refresh itself).

Hmmm. I would have thought that the nocache headers would negate the browser even attempting to load from the cache (which is the behaviour I was under the impression caused the error). Odd that.

The issue is that re-coding for GET is non-trivial, and we don't necessarily want people to be able to bookmark internal pages in the site in any case.

Well, you can solve this problem with a temporary cookie anyway, or a session id if you need compatibility. For example, you recode for GET, and you add in a wee bit of code to set a cookie with no expiry (which will expire when the browser closes), and check for the cookie on page load. If it isn't there, well, they're obviously coming from either an external link or a bookmark, in which case you can refresh them to a clean form or another page entirely. Or again, if you require compatibility with non-cookie-enabled browsers, you can use a session id which is cleared from the database periodically, say every hour unless recent activity has taken place.

That make sense to you?

[FYI, there is another simple alternative, which is to check for a HTTP_REFERER on load. This is less reliable than a random id though, as it's easier to spoof.]

adam