Some forms get submitted twice

VERIFIED DUPLICATE of bug 61363

Status

()

Core
HTML: Form Submission
P1
critical
VERIFIED DUPLICATE of bug 61363
16 years ago
15 years ago

People

(Reporter: Harald Gill, Assigned: John Keiser (jkeiser))

Tracking

Trunk
Future
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1a+) Gecko/20020709
BuildID:    2002070908

Using Mozilla, when I make a fund transfer on the Royal Bank online banking
system, a double payment is always posted to the bank. If I use IE or Netscape,
only a single transfer is posted. Somewhere along the line, Mozilla is sending
the transfer request twice.

Reproducible: Always
Steps to Reproduce:
1. Click on Transfer button
2. Enter amount and press Transfer Now button
3. Click on Confirm Transfer button.

Actual Results:  Checking my balances, the transfer was posted twice.

Expected Results:  A single transfer should have happened.

I don't have accounts at other institutions, so I don't know if other banks have
the same problem.
-> Form submission

There is somewhere a bug about that forms are 2x posted...
Assignee: Matti → alexsavulov
Component: Browser-General → Form Submission
QA Contact: asa → vladimire

Comment 2

16 years ago
See: bug 90392, bug 61363, bug 130579, bug 72906. Might be a dupe of one of these.

Comment 3

16 years ago
Not a crash 

==> not CRITICAL.

Updated summary (was: "Problem when online banking")
Severity: critical → major
Summary: Problem when online banking → Some forms get submitted twice
(Reporter)

Comment 4

16 years ago
Critical is also data loss, or in this case banking information duplicated. That IS critical. 
sending to somewhere where it may be fixed....

Harald, would you mind doing the following?  Set the environment variables

NSPR_LOG_MODULES="nsHttp:5"
NSPR_LOG_FILE="C:\mozillalog.txt"

(or whatever filename you want).  Then start Mozilla, go to the site, perform
such a transfer (for a small amount, I would hope), then quit Mozilla?  Try to
load as few pages as possible so as to keep the log a sane length....

I can understand not wanting to do that, and that's OK too, but if it's possible....
Assignee: alexsavulov → jkeiser
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 6

16 years ago
How do I set those variables?
set NSPR_LOG_MODULES="nsHttp:5"
set NSPR_LOG_FILE="C:\mozillalog.txt"

in a prompt window, then launch Mozilla from that prompt.

Alternately, you can set environement variables from the advanced properties 
of "My Computer" on Win2k, if I recall correctly.
(Reporter)

Comment 8

16 years ago
i did what you suggested, and can't find the log files.
The log file should be in C:\mozillalog.txt (or whatever value you gave for 
NSPR_LOG_FILE)...  Is it not?
(Reporter)

Comment 10

16 years ago
No, that was the first place I looked. I just copied and pasted your
examples into a command prompt window and then ran Mozilla from the same
command prompt. No file showed up when I looked for it. I even did a search
on the filename for my entire system, and came up with nothing.
hm... so a Windows developer here said that the quotes should not be there (so
the correct syntax is:

set NSPR_LOG_MODULES=nsHttp:5
set NSPR_LOG_FILE=c:\mozillalog.txt

).  Could you please try that?  (and my apologies for getting it wrong the first
time).

Comment 12

16 years ago
See also bug 159859 that might have the same cause.
(Reporter)

Comment 13

16 years ago
Created attachment 96030 [details]
Contains the logfile created according to the instructions given in Comment #11. I zipped it to get it to the size required to attach to the bug report.
(Reporter)

Comment 14

16 years ago
BTW, I clicked on the link above to download the file, under Mozilla, the
download was Attachment.cgi, not *.zip. Why does Mozilla default to a *.cgi
extension, instead of the actual extension for the file?
because mozilla does not know what the actual extension is (bugzilla either does
not know it or just does not transmit it. yes there's a bug on that, though I
don't know its number offhand)
(Assignee)

Comment 16

16 years ago
For those who are looking, the critical double-posting section appears to be
where the cookie PPAGE=OnLineTransfer is set (it uses a single CGI with a cookie
to tell it where it is).  A POST request appears to be sent twice.  Here is the
first request and response:

0[234068]: http request [
0[234068]:   POST /cgi-bin/rbaccess/rbcgi3m01 HTTP/1.1
0[234068]:   Host: www1.royalbank.com
0[234068]:   User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.1b) Gecko/20020812
0[234068]:   Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1
0[234068]:   Accept-Language: en-us, en;q=0.50
0[234068]:   Accept-Encoding: gzip, deflate, compress;q=0.9
0[234068]:   Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
0[234068]:   Keep-Alive: 300
0[234068]:   Connection: keep-alive
0[234068]:   Cookie: PPAGE=OnLineTransfer; BALF22=HTPCBINET;
F100=1/WO2/-H3TdqqlvSFnPqg-McBNLO2KvSEkFVIMwg-LyS3HV181ff-kdd1OLCZMw-.hykbUnQn1PLFX..TIRNBIAdUd2w??/FQAAAA??/S0/PB
0[234068]: ]

...

1256[f832b0]: http response [
1256[f832b0]:   HTTP/1.1 200 OK
1256[f832b0]:   Date: Tue, 20 Aug 2002 16:20:18 GMT
1256[f832b0]:   Server: Apache/1.3.26 (Unix) mod_ssl/2.8.9 OpenSSL/0.9.6c
1256[f832b0]:   Set-Cookie:
F100=1/WO2/BfUtQ3zNArwZL4MUgIEObGDGxKcQyT5o537GNgtRxPWx.S.s4z20tGhKEOuji2JV3.fAWMAKyTfGGA-p8PV5rQ??/FQAAAA??/S0/PB;
path=/;
PPAGE=OnLineTransfer; path=/
1256[f832b0]:   Content-Length: 005264
1256[f832b0]:   Keep-Alive: timeout=15, max=178
1256[f832b0]:   Connection: Keep-Alive
1256[f832b0]:   Content-Type: text/html; charset=ISO-8859-1
1256[f832b0]: ]

Here is the section where I believe we would be making the decision to stop:

1256[f832b0]: nsHttpTransaction::Read [this=3288528 count=4096]
1256[f832b0]: mSource->Read [rv=0 count=4096 countRead=1168]
1256[f832b0]: nsHttpTransaction::HandleContent [this=3288528 count=1168]
1256[f832b0]: nsHttpTransaction [this=3288528 count=1168 read=1168
mContentRead=5264 mContentLength=5264]
1256[f832b0]: nsHttpConnection::OnTransactionComplete [this=3236408
trans=3288528 status=0]
1256[f832b0]: nsHttpTransaction::Read [this=3288528 count=2928]
1256[f832b0]: nsHttpTransaction: listener returned [rv=0]
1256[f832b0]: mTransaction->OnDataReadable() returned [rv=0]
1256[f832b0]: nsHttpTransaction::OnStatus [this=3288528 status=804b0006]
1256[f832b0]: nsHttpConnection::OnStopRequest [this=3236408 ctxt=0 status=0]
1256[f832b0]: nsHttpTransaction::OnStopTransaction [this=3288528 status=0]
1256[f832b0]: nsHttpHandler::ReclaimConnection
[conn=3236408(www1.royalbank.com:443) keep-alive=1]
1256[f832b0]: adding connection to idle list [conn=3236408]
1256[f832b0]: active connection count is now 0
1256[f832b0]: nsHttpHandler::ProcessTransactionQ_Locked
1256[f832b0]: >> unable to process transaction queue at this time
0[234068]: nsHttpChannel::OnDataAvailable [this=264e0a8 request=328852c offset=0
count=5264]
0[234068]: nsHttpChannel::OnStopRequest [this=264e0a8 request=328852c status=0]
0[234068]: nsHttpChannel::FinalizeCacheEntry [this=264e0a8]
0[234068]: nsHttpChannel::CloseCacheEntry [this=264e0a8 status=0]
0[234068]: nsHttpTransaction::DeleteSelfOnConsumerThread [this=3288528]
0[234068]: Destroying nsHttpTransaction @3288528
0[234068]: nsHttpHandler::NewURI
0[234068]: nsHttpHandler::NewURI
0[234068]: nsHttpHandler::NewURI
0[234068]: nsHttpHandler::NewProxiedChannel [proxyInfo=0]
0[234068]: Creating nsHttpChannel @3330168
0[234068]: nsHttpChannel::Init [this=3330168]
0[234068]: host=www1.royalbank.com port=-1
0[234068]: uri=https://www1.royalbank.com/cgi-bin/rbaccess/rbcgi3m01

... and our second request, for good measure.

0[234068]: http request [
0[234068]:   POST /cgi-bin/rbaccess/rbcgi3m01 HTTP/1.1
0[234068]:   Host: www1.royalbank.com
0[234068]:   User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.1b) Gecko/20020812
0[234068]:   Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1
0[234068]:   Accept-Language: en-us, en;q=0.50
0[234068]:   Accept-Encoding: gzip, deflate, compress;q=0.9
0[234068]:   Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
0[234068]:   Keep-Alive: 300
0[234068]:   Connection: keep-alive
0[234068]:   Referer: https://www1.royalbank.com/cgi-bin/rbaccess/rbcgi3m01
0[234068]:   Cookie: PPAGE=OnLineTransfer; BALF22=HTPCBINET;
F100=1/WO2/BfUtQ3zNArwZL4MUgIEObGDGxKcQyT5o537GNgtRxPWx.S.s4z20tGhKEOuji2JV3.fAWMAKyTfGGA-p8PV5rQ??/FQAAAA??/S0/PB
0[234068]: ]


Note that we *do not* do a HEAD request for the second POST, only for the first
POST.
Darin?  Steve?  Any ideas what's up here?

raising severity to critical; double-submits of POST data are not good.
Severity: major → critical

Comment 18

16 years ago
I don't see anything obvious in the traffic.  After the first post, the response
is modifying the value of a cookie, and the second post indeed sends out the
modified value.

I'd need to see the source of the page itself.  Can someone who has an account a
the Royal Bank get to their fund-transfer page, do a view-source, and attach
that source to this bug report.

Comment 19

16 years ago
hmm... at first i feared we were automatically resending the POST request in
response to a prematurely closed connection (having read only EOF), but that
does not appear to be the case.  instead, it looks like something above necko is
driving the subsequent POST requests.  so, i agree with morse... it would be
good to see the document.

Updated

16 years ago
Priority: -- → P1

Comment 20

16 years ago
I have found a similar problem to this with Mozilla 1.0.  When clicking on a 
link, the server receives two requests.  I was developing a page with 'Next' 
and 'Previous' buttons that take the user to the next and previous pages in a 
sequence.  When a user clicked on these links the page returned was not the 
next in the series but the one after.  A break point in the server code showed 
the second request arriving sometime after the first, but before the first 
request has been comlpleted.

I attempted to whittle down the page to just the code which causing the 
problem.  The page is generated using Tomcat 3.2 and quite a complex JSP that 
uses an XSLT stylesheet to render some XML, so I did a view source and saved 
the resulting page to disk.  However, when that HTML is loaded into Mozilla the 
problem goes away (only one request is submitted when the link is clicked).  
Thinking it might be something to do with Tomcat or caching, I copied the HTML 
over the top of the original JSP. This delivers the same HTML to the browser, 
only it does not take so long to generate it  This worked OK (it only submitted 
one request).  I began to suspect it was the amount of time taken to generate 
the page.

Next I added some code to the JSP to make it pause for 12 seconds before the 
last bit of the HTML it is delivered to the browser.   Bingo!  Mozilla starts 
to submit the request a second time.

I have worked around the problem (my next and previous links specify the page 
to goto), so I don't need this fixed, but I thought you might like to know what 
I found.
Bulk moving P1-P5 un-milestoned bugs to future. 
Target Milestone: --- → Future

Comment 22

16 years ago
Talked with the reporter and he said that moving the charset to the beginning of
the file fixes the problem.

*** This bug has been marked as a duplicate of 61363 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE

Comment 23

15 years ago
verifying
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.