Cycling UK Forum

admin wrote:This is odd. I can't see any reason why you shouldn't be able to just go back to the search results list.

Can you tell me the order of events that lead to you seeing "page expired" in your browser when you return to the search results list?

It's a browser-specific thing. If the page to which you want to return was generated from HTML POST variables, the browser has two options:

1. Show you what was there when first generated; or
2. Request the page again from the server.

In the latter case, the browser must resend the post variables to the server. Often this is not a problem. However, if the page was something like confirmation of a purchase and the website didn't have appropriate safeguards, refreshing the page in this way could result in your repeating the purchase. So browsers should either warn you and get your permission to resend the variables (like Firefox) or tell you the page has expired (like IE).

HTH,

Geoff

Graham wrote:( I'm rather surprised that Microsoft have not FORCED you to upgrade their Internet Explorer version. )

I suspect that they can't because of the implications for users of applications that IE8 breaks. FWIW, I know of some companies that still use IE6 because IE7 breaks 'mission-critical' applications.

GeoffL wrote: ... 'mission-critical' applications.

"Houston - we've had a problem."

Thanks for this Geoff. At least I know it's not something I'm doing utterly stupid. (Now, what did I do with the keys for the loony module? )

TC: Unfortunately, I posted without looking 'under the hood'. In a previous post:

admin wrote:Technical stuff: The search page uses a query string in the URL, and the GET method,...

I've just checked, and he's right. The scenario I wrote about up-thread relates to the POST method. However, while I can't remember ever seeing this behaviour, it should be possible for a browser to detect the presence of a querystring (aka GET variables) and to consider the page expired in the same way as it can for POST variables.

That said, I've just googled for "IE7 page expired GET" and discovered that you are not alone. It seems that the same problem existed in IE6 but was fixed in an update. Another reports that the problem seems to be IE considering all active content to have expired. All pages with a .php extension fall in to this category and the search page is a PHP script.

FWIW, the easiest way I've found of using search results is to open each link in a new tab with Ctrl+middle-click. However, that doesn't seem to work in IE as the new tab opens behind the current one and so the best with that browser is probably Shift+Click to open the link in a new window. This leaves the search page open so that you can follow other results at your convenience.

HTH,

Geoff

Another oddity of old versions of IE, then! To be fair to Microsoft, they've moved a long way from the bad old days of IE6, which was so incompatible with web standards it was amazing it worked at all. IE7 was an improvement, but IE8 and IE8 are an awful lot better, faster, and more secure.

A POST request is something that will do something at the server end, such as add a message, send an email, update a database, confirm an order. So it is never safe to repeat a POST request, and most browsers will prompt you if you try to do so. A POST request sends data, and is almost always generated by a form.

A GET request is always safe to repeat, so a browser should always just re-request the URL, without prompting. A GET request reads data, and is usually generated by a simple link but some forms, such as search forms, also use GET: you can see the search terms in the browser's address bar if they do.

There is no way to guess the method of generation of the webpage based on characters in the URL. Just because there's ".php" in the URL doesn't mean the page is dynamically generated, nor that it changes with each request. Even if a GET requested page has "expired", there's no danger in requesting it again, and the browser shouldn't prompt to do so.

admin wrote:A POST request is something that will do something at the server end, such as add a message, send an email, update a database, confirm an order. So it is never safe to repeat a POST request, and most browsers will prompt you if you try to do so. A POST request sends data, and is almost always generated by a form.

A GET request is always safe to repeat, so a browser should always just re-request the URL, without prompting. A GET request reads data, and is usually generated by a simple link but some forms, such as search forms, also use GET: you can see the search terms in the browser's address bar if they do.

Provided that you're not using an enctype of multipart/form-data, the difference between post and get is notional only as whatever you can send as a POST variable (i.e. passed in HTTP headers) can also be sent as a GET variable (i.e. passed on the querystring). Reloading a page with a querystring has the same effect as reposting. This is recognised in the latest versions of PHP which have $_REQUEST, which is an associative array that combines $_POST, $_GET, and $_COOKIE. A post variable named "myvar" and a get variable named "myvar" can both be accessed by the phpBB application as $_REQUEST['myvar'] and are treated identically at the server. Thus any difference is only in the way that a browser handles the 'Go Back' event. Some browsers display the cached rendering for GET and resubmit for POST, but it is feasible that a browser could perform either action for either method.

Edited to add: Those interested in the nitty-gritty can get more info from section 8 of http://www.w3.org/Protocols/HTTP/1.0/spec.html#Operation.

HTH,

Geoff

I expect the cycling people have stopped reading now , so, to be accurate:

GeoffL wrote:whatever you can send as a POST variable (i.e. passed in HTTP headers) can also be sent as a GET variable (i.e. passed on the querystring). Reloading a page with a querystring has the same effect as reposting

No, not at all, for two reasons:

• The semantic difference between GET and POST is critical. A GET is effectively a "read" operation, while a POST is a "write" operation. Thus a browser can safely repeat a GET operation, but should never repeat a POST operation without asking first. The HTTP protocol is quite explicit about this: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
• GET and POST pass arguments/data differently. A GET request is merely a request for the resource specified by the URL, there can be no body data in the request. A POST request has a URL, and it also has body data. Unless the server also accepts this data as GET arguments (which is potentially dangerous), then you cannot replace a POST with a GET that will do the same thing. For example, there is no way to log into this Forum with a GET request like http://forum.ctc.org.uk/ucp.php?mode=login&login=GeoffL&password=fred - the login and password arguments are just ignored: you have to POST those arguments to log in.

Some web developers mis-understand this (myself included, a long time ago!) and use a link for actions like "delete this item" - then they wonder why all their data has gone just after Google's web crawler has visited the site!

GeoffL wrote:A post variable named "myvar" and a get variable named "myvar" can both be accessed by the phpBB application as $_REQUEST['myvar']

Yes, they can be, but for anything that modifies things on the server you'd want to use $_POST for safety. Where a web server is specifically looking for POST data, you can't fool it by sending that data as GET arguments, and any re-POSTing will need to be confirmed by the user.

GeoffL wrote:Thus any difference is only in the way that a browser handles the 'Go Back' event. Some browsers display the cached rendering for GET and resubmit for POST, but it is feasible that a browser could perform either action for either method.

Yes, a browser can simply re-display the last page without re-sending a request to the server, but if it does re-send the request, POST and GET are quite different. Performing a GET again merely re-requests the same URL, which is always safe. Performing a POST again re-requests the same URL, but also re-sends the POST data in the request body. A POST request, by definition, can make changes at the server end, so POST actions should always be confirmed before being executed.

A GET is just a URL, so can be bookmarked. A POST is URL plus data, and cannot be bookmarked.

Anyway, it appears that "page has expired" for a GET request is a bug in early versions of Internet Explorer. Upgrading to a current web browser will fix the problem.

GeoffL wrote:....you are not alone. ...

Too right I'm not. As we speak, there's some sort of UFO down the garden, and I'me getting readdy to play the five tones.

FWIW, the easiest way I've found of using search results is to open each link in a new tab with Ctrl+middle-click. However, that doesn't seem to work in IE as the new tab opens behind the current one and so the best with that browser is probably Shift+Click to open the link in a new window. This leaves the search page open so that you can follow other results at your convenience.

Somehwre further up, si suggested checking each result in a new tab and I've been doing that ever since - on this occasion I forgot.

Despite the jocular tone, I'm very grateful to people who take the time and trouble to analyse these things and offer explanations and solutions. FWIW, I'm not doing this on a Commodore 64. The computer came with the software installed a little over 2 years ago.

Two years is a long time in the world of web browsers!

If you can update IE that would be good for all sorts of reasons. As someone else was, I'm a little surprised that IE hasn't asked you to update it by itself. It's not a difficult task, you just use Windows Update. Here's how to get started:

http://windows.microsoft.com/en-GB/wind ... t-Explorer

FWIW,
I'm a cycle person and am still reading this!
Also, we're AppleMac people.

Back in the day when we first became computerised - 2001 - our in-house browser was Safari on our iBook. We're going back to the days of Macosx 10.1, and Safari wouldn't work with some websites. We eventually, because of frustration, "upgraded" to Firefox and found it brilliant - and Safari just sat there unused in our Applications folder.

This situation remained throughout our subsequent upgrades to MacBooks and iMacs and right up to very recently. Firefox latest upgrade 9.0.1 became problematical - crashing and going all weird and uncommunicating. We've now gone back over to Safari, and it's perfect.

Moral?
Don't stay stuck in the mud - because things move on.

@admin:

As inconsistent as this might seem, we are both correct. The specification for HTTP 1.0 (which as I understand it is one step on from a request for comments) states:

Applications must not cache responses to a POST request because the application has no way of knowing that the server would return an equivalent response on some future request.

However, that doesn't mean that it's impossible for a badly-behaved browser to cache the response to a POST request or that a browser, badly-behaved or not, must cache the response to a GET request.

While I understand the intended difference between POST and GET, 'mechanically' and pragmatically they are equivalent in the same way as the PHP mysql and mysqli modules are functionally equivalent. You can replace a POST with a GET that will do the same thing provided that your application makes the change at both ends. Of course, GET is less secure than POST, but that doesn't mean you cannot replace POST with GET -- particularly in locations that are inaccessible to all but logged in users and/or where your application uses something like pre-shared keys to authenticate the user.