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
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
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
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.
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?
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).
See also bug 159859 that might have the same cause.
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.
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)
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: http request [ 0: POST /cgi-bin/rbaccess/rbcgi3m01 HTTP/1.1 0: Host: www1.royalbank.com 0: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020812 0: 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: Accept-Language: en-us, en;q=0.50 0: Accept-Encoding: gzip, deflate, compress;q=0.9 0: Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66 0: Keep-Alive: 300 0: Connection: keep-alive 0: Cookie: PPAGE=OnLineTransfer; BALF22=HTPCBINET; F100=1/WO2/-H3TdqqlvSFnPqg-McBNLO2KvSEkFVIMwg-LyS3HV181ff-kdd1OLCZMw-.hykbUnQn1PLFX..TIRNBIAdUd2w??/FQAAAA??/S0/PB 0: ] ... 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: nsHttpChannel::OnDataAvailable [this=264e0a8 request=328852c offset=0 count=5264] 0: nsHttpChannel::OnStopRequest [this=264e0a8 request=328852c status=0] 0: nsHttpChannel::FinalizeCacheEntry [this=264e0a8] 0: nsHttpChannel::CloseCacheEntry [this=264e0a8 status=0] 0: nsHttpTransaction::DeleteSelfOnConsumerThread [this=3288528] 0: Destroying nsHttpTransaction @3288528 0: nsHttpHandler::NewURI 0: nsHttpHandler::NewURI 0: nsHttpHandler::NewURI 0: nsHttpHandler::NewProxiedChannel [proxyInfo=0] 0: Creating nsHttpChannel @3330168 0: nsHttpChannel::Init [this=3330168] 0: host=www1.royalbank.com port=-1 0: uri=https://www1.royalbank.com/cgi-bin/rbaccess/rbcgi3m01 ... and our second request, for good measure. 0: http request [ 0: POST /cgi-bin/rbaccess/rbcgi3m01 HTTP/1.1 0: Host: www1.royalbank.com 0: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020812 0: 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: Accept-Language: en-us, en;q=0.50 0: Accept-Encoding: gzip, deflate, compress;q=0.9 0: Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66 0: Keep-Alive: 300 0: Connection: keep-alive 0: Referer: https://www1.royalbank.com/cgi-bin/rbaccess/rbcgi3m01 0: Cookie: PPAGE=OnLineTransfer; BALF22=HTPCBINET; F100=1/WO2/BfUtQ3zNArwZL4MUgIEObGDGxKcQyT5o537GNgtRxPWx.S.s4z20tGhKEOuji2JV3.fAWMAKyTfGGA-p8PV5rQ??/FQAAAA??/S0/PB 0: ] 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
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.
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.
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
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
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.