Version: (using KDE KDE 3.4.1) Installed from: Fedora RPMs When the response of a POST request includes an HTTP Refresh header (or the equivalent using a <meta http-equiv=Refresh ...> tag) and the URL contained in that header is the same URL as the one accessed by the request, Konqueror issues a POST request instead of a GET request. This makes the popup "Do you want to resend the form data?" appear. That behavior is wrong. A refresh header means: "Go to this URL after this amount of time", not "Refresh this page after this amount of time". So only GET requests should be issued, and the form data should never be resent. The correct behavior is exhibited by Mozilla and IE.
I also see this on Konqueror 3.5.1. I'm writing a website in PHP. To avoid the "do you really want to resend" message, I save posted data to session and reload the page with header('location: whatever');. Works perfectly in Firefox and Opera, and IE I'm pretty sure. But Konqueror doesn't "get it", it thinks the reloaded page has been reached with a POST.
Hehe, this bug just bit me again! Only 2 months ago I made comment #1, and I already forgot about the issue. Anyway, the problem is still there in 3.5.2. I'm attaching a small testcase. It works like this: 1) press the submit button 2) the page is requested with POST 3) a number is incremented 4) the page is reloaded with GET 5) the number is shown 6) GOTO 1) If I press Reload in Firefox or Opera, the current page is reloaded (with GET, _not_ incrementing the number), Konqueror shows the "do you really want..." message. On the other hand: The Back-button works in Konqueror, but not in Firefox or Opera. <?php session_start(); if ($_SERVER['REQUEST_METHOD']=='POST') { //inc post_number if (!array_key_exists('post_number', $_SESSION)) {$_SESSION['post_number']=0;} $_SESSION['post_number']++; //redirect header('Location: http://localhost/test/test.php'); exit(); } else { //show a simple form echo "<form method='post'><input name='whatever'><input type='submit'></form>"; //show post_number if (array_key_exists('post_number', $_SESSION)) {echo 'Post number: '.$_SESSION['post_number'];} } ?>
Ups, obviously the redirect has to go to whereever the script is located...
The Xoops portal system's admin module uses post-refresh a lot and because of this bug the admin module is really annoying to use in Konqueror. This is a bad bug.
Here's another example to trigger this bug. At least with KDE 3.5.4, you can save this to a regular .html file and access it like file:///tmp/bug.html i.e. no need to have a HTTP server. <html> <head><meta http-equiv="refresh" content="5; URL=?foo"></head> <body> Click the button to trigger the bug. <form action="?foo" method="post"><input type="submit"></form> </body> </html> Before clicking the button, the page refreshes normally every five seconds. After clicking, the next automatic refresh will prompt about resending data. To trigger this bug, it is essential, that <form action=...> and refresh URL are the same. I can see three distinct cases, which may need different handling: - User requests page refresh: Konqueror's confirmation about resending data is very good here. - http-equiv="refresh" content="5; URL=?foo": In KDE 3.5.4, this acts like the user-requested refresh, which is wrong. The page should be refreshed without questions and without resending anything. - http-equiv="refresh" content="5": It's unclear to me what would be the correct behavior regarding to resending data. Other browsers seem to do this like the content="5; URL=?foo" case i.e. not resending anything. Probably Konqueror/KHTML should do the same. Imprtant detail: Once an automatic refresh has occurred, the browser should forget posted data. That is, once automatic refresh has reloaded the page without resending any data, refresh triggered by the user should not ask for resending data. (Firefox fails this.)
Tested the first testcase on konqueror 4.0.3. Clicking on "submit" increments the counter. Clicking on "reload" action will show the "resend" dialog and after the counter is incremented. The same happen pressing F5.
*** This bug has been marked as a duplicate of bug 187518 ***