Closed Bug 359690 Opened 18 years ago Closed 15 years ago

Forms Double Posting

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Version:
2.0 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: clint, Unassigned)

Details

(Whiteboard: [closeme 2010-02-01])

User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; InfoPath.1) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0 I created a content management system that uses both POST and GET data to navigate. The GET data tells the system what to do, such as edit, add, etc. The POST data is what is entered into forms. When posting updates, Firfox seems to double post. Once with the data entered, and once with blank data. These are .php files connecting to a MYSQL database. I had the program e-mail me everytime the UPDATE script was ran. The e-mail outputs the time, and then outputs the MYSQL script, then outputs the user agent. Here is what I got: EMail 1: SUBJECT: November 06, 2006 12:05:14 PM 0.56983900 1162832714 UPDATE `pages` SET `title` = 'Hello', `text` = 'trying this is in Firefox', `image` = '', `layout` = '1', `live` = 'n', `section` = '10', `group_id` = '', `featured` = 'n', `call_header` = '', `call_text` = '', `update_date` = '1162832714' WHERE `id` = '54'Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0 EMail 2: Subject: November 06, 2006 12:05:15 PM 0.95907800 1162832715 UPDATE `pages` SET `title` = '', `text` = '', `image` = '', `layout` = '', `live` = 'n', `section` = '', `group_id` = '', `featured` = 'n', `call_header` = '', `call_text` = '', `update_date` = '1162832715' WHERE `id` = '54'Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0 Where in this second e-mail, the little data that is filled in is automatic, such as the time, and if there is no data, use "n'. There appears to be less than 1/2 a second between them. The 0.xxx number is microtime, the second number is the UNIX timestamp. So firefox is breaking these forms. And I've got about 120 of them over many different sites. I first noticed this Saturday when demonstrating a form. These forms worked fine for the 1.X releases. This also appears to happen after the inital page has rendered. The page loads with all of the correct data, but when viewing the database afterwards, the record is blank. Also, I'd like to note that this has happened on 3 different machines in 3 different locations. All were MS Win XP. Reproducible: Always Steps to Reproduce: 1. Log Into content Management 2. Open Record 3. Submit Chnages 4. Data appears on the page, but the database is empty. Actual Results: Blank Database record, but correct data shown on form. I'm thinking it happens like this: Database Updated Correctly Database Info grabbed Database Updated with Blank Data Expected Results: Data should be what was inserted into forms.
If this behavior is the same as what would happen if you requested the page without POSTing any data to it, then perhaps your page has a link to embedded media referring to the current URL (e.g., <img src=""> -- see bug 225554) or conflicting character set information in the HTTP header and <meta> tags (see bug 236858).
I use this PHP code in all my session includes, which would be universal... header("Cache-control: private"); // IE 6 Fix. I will try disabling that and try again. I don't see any image tags without the src.
Removing that does not change anything.
Removing: <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> makes no difference.
This bug is such a pain. I don't like telling my clients that they can not use Firefox with the administration.
A testcase with the html code involved would be useful here.
The following testcase does post a form double on "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6" --html snip <html> <head> <title>FF Double Post</title> </head> <body> <script>nonsense</script> <form method="post"> <input type="submit" value="double me"> </form> <!-- NONSENSE-BUT-FULL-LOAD!NONSENSE-BUT-FULL-LOAD! [... blow your html up to 20KB+ ] --> </body></html> --/html snip Looking a the Access Log, you'll notice to request at the same time: --apache log xxx.xxx.xxx.xxx - - [29/Aug/2007:12:17:52 +0000] "POST /doublepost.html HTTP/1.1" 200 19487 "http://sp.dev.blueend.com/doublepost.html" "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6" xxx.xxx.xxx.xxx - - [29/Aug/2007:12:17:52 +0000] "POST /doublepost.html HTTP/1.1" 200 19487 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6" --/apache log My Comments/Testvariations showed: 1.) The double request seems to depend on the SIZE of the RESPONSE from the server and the invalid Script-Tag. If you drop the response under a certain size (in my scenario this was about 20KB - if you cannot reproduce it with 20KB try a bigger answer..) the form is not reposted. 2.) Slight variations in the script tag, such as "<script>no blank sense</script>" seem to make the bug dissappear also. --> This is propably the answer why so few occurence have been seen. (Took me ~8 hours to trace this and produce a testcase) 3.) Deactivate JS -> No Bug 4.) <form onsubmit="alert('count me');"> will be triggered only once 5.) I have tested 2 different Servers (Debian Linux Apache 1.3 and Fedora Apache 2) - same result 6.) I have varied on encoding headers sent (UTF-8 and ISO-8859-15) - same result [so i'm assuming it's different from the charset thing mentioned in bug #236858 (Repeating GET requests)
Stefan> Is this behavior visible with LiveHTTPHeaders or Firebug ? If I understand well, to reproduce this bug, the server has to send a response just below 20KB ?
Hi Thomas, yes this behaviour is visible in LiveHTTPHeaders (POST -> HTTP 200 returns -> POST -> final Answer served) In my case the total file was 19487 bytes, but i also reproduced this with files being larger than 20KB, but not smaller (So the server has to send a response with MORE than ~20KB).
This turned out to be a Firebug (Extension) issue... sorry.
If you would like, I can offer you personal access to our cms that cuases the bug. We use it often, and I have at least one test site you can try it on.
(In reply to comment #11) > If you would like, I can offer you personal access to our cms that cuases the > bug. We use it often, and I have at least one test site you can try it on. As I told you in the email, you can send me credentials, I'll try to reproduce this bug.
clint, still see this?
Severity: critical → major
Keywords: testcase-wanted
Whiteboard: [closeme 2010-02-01]
Version: unspecified → 2.0 Branch
Closing as incomplete. Should the information be added this can be reopened.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.