284994 - mozilla-based browsers post form multiple times

Status: RESOLVED EXPIRED

(Core :: DOM: Core & HTML, defect)

Description

[bradley mclain]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

Since I am not allowed to reopen a defect, this is a 'dupe' of 153405.  Mozilla,
Firefox, Epiphany, etc. do this. The following is text I added last november to
that defect:

Please look at the following.  It shows debug output for a web application.  The
first entry (Nov 11, 2004 5:59:21) is an app deploy, then submit a form using
IE.  There is only one form submission.  The second entry (Nov 11, 2004 6:00:31
AM) is an app redeploy, then submit the form using Firefox.  There are three
form submissions.  I verified a single submission using Opera as well, and found
3 submits using Mozilla.  the long ints are time stamps.

I can be found here:  bradley_mclain at yahoo.com

Nov 11, 2004 5:59:21 AM org.apache.catalina.core.StandardHostDeployer install
INFO: Installing web application at context path /stayinstep from URL
file:C:/Cygwin/usr/local/jakarta-tomcat-5.0.27/webapps/stayinstep
requestURL:     >>>http://localhost:8080/stayinstep/login.htm<<<
requestURI:     >>>/stayinstep/login.htm<<<
action: login
1100181573557

Nov 11, 2004 6:00:31 AM org.apache.catalina.core.StandardHostDeployer install
INFO: Installing web application at context path /stayinstep from URL
file:C:/Cygwin/usr/local/jakarta-tomcat-5.0.27/webapps/stayinstep
requestURL:     >>>http://localhost:8080/stayinstep/login.htm<<<
requestURI:     >>>/stayinstep/login.htm<<<
action: login
1100181646760
requestURL:     >>>http://localhost:8080/stayinstep/login.htm<<<
requestURI:     >>>/stayinstep/login.htm<<<
action: login
1100181647369
requestURL:     >>>http://localhost:8080/stayinstep/login.htm<<<
requestURI:     >>>/stayinstep/login.htm<<<
action: login
1100181647838

Reproducible: Always

Steps to Reproduce:
1.  create form - say a login page
2.  post form to server
3.  note 3 posts of same information.

Actual Results:  
the posted data shows up 3 times at the server.

Expected Results:  
the browser should post the data once only

full details are in 153405.

Comment 1

[Kenneth Herron]

Bradley, can you reproduce this with a current version of mozilla? The logfile
sample you included is from last november.

Can you provide a URL which is accessible from the Internet, or a sample page,
which allows someone to reproduce this problem? You've provided evidence
suggesting the problem exists, but not enough detail to let someone reproduce it.

Comment 2

[bradley mclain]

Attachment: html output of login page, including form.

shows html of page that triggers multiple submits from Mozilla-based browsers.

Comment 3

[bradley mclain]

Attachment: contains server trace of one form submission from Firefox 101.

Comment 4

[bradley mclain]

attached are two text files.  The first shows the html of the login page for the
site.  the second shows trace log output demonstrating multiple submits.  I have
upgraded Firefox on both Linux and Windows to 1.0.1, and the issue persists.

look for log entries like the following:
ControllerServlet.doPost() - requestURL:
>>>http://localhost:8080/stayinstep/login.htm<<<

these show a new request arriving at the webserver.  It is important to note
that neither Opera or IE exhibit this behavior, but Firefox, Mozilla and
Epiphany do.

Unfortunately, this site is not yet available publicly.  If it is important,
then I can expose it to you.

if it would help, I can also attach a server trace for an IE submit.

Comment 5

[Ben Fowler]

Are they all POST requests or is one a GET. See Bug 284738 "Firefox sends 
additional GET for a POST"

Comment 6

[Hermann Schwab]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050224
I have the SSL warnings enabled in Preferences ->Privacy&Security -> SSL.
When I load a bug from the buglist into a new tab, the warning is shown three
times. I don´t see this in builds some days older or some days newer.

https://bugzilla.mozilla.org/buglist.cgi?product=Core&product=Firefox&product=Mozilla+Application+Suite&product=Thunderbird&product=Toolkit&bug_status=UNCONFIRMED,NEW,ASSIGNED,REOPENED,RESOLVED&chfield=%5BBug%20creation%5D&chfieldfrom=-0d
Right-click on bugs and open in new tab.

Comment 7

[bradley mclain]

Attachment: shows multiple GET requests accompanying a POST

I added a log statement to differentiate between GET and POST (i normally route
both through the same logic), and indeed the additional requests are GETs. 
Look for this line in the file:

ControllerServlet.doGet() - Received GET request

The sequence is a POST to a Login processor that then forwards to a Landing
processor.  Each time you see the above log entry, followed by:

ControllerServlet.doPost() - requestURL: 
>>>http://localhost:8080/stayinstep/loginPage.htm<<<

that means there was a spurious GET along with the POST.

So I think the supposition that this may be related to another defect is
probably correct.  All I would add is that there seem to be several GETs with
each POST, not just one.  In this snippet you see 3 GETs, followed by the POST
to the LoginAction processor.  Subsequently, you see a POST to LandingAction
(which is legitimate and expected --> it was forwarded) followed by another GET
to login and another GET to landing.

All of this was created by entering credentials and clicking 'sign in' once. NB
--> Sign In is input type="image", in case that matters.  I was seeing this
issue before using such input types, though.

I'll also attach a trace with the request coming from IE.

Comment 8

[bradley mclain]

Attachment: server trace with request from IE6

This shows the same request coming from an IE browser, w/o all the extra GETs.

Comment 9

[bradley mclain]

CORRECTION:  in the file named 'shows multiple GET...' the first 3 GETs are
associated with a different request, though they too are spurious as I only
requested the page once.

There are, however, an additional GET for each POST lower in the file associated
with the login and landing.  When compared to the IE trace, the file clearly
shows the extra GETs.

Comment 10

[Ben Fowler]

See Bug 284738 comment 7

Comment 11

[bradley mclain]

I do not have HTMLValidator installed.  The box I am testing on right now is
running Linux.  I checked, and the HTMLValidator is available only for Windows.

I don't think that has been the issue, unfortunately.  I am trying to determine
if there is some defect in my code that only shows up with mozilla-based
browsers, but I have had no eureka as of yet.  My assumption all along is that
my code is bad somehow, but I haven't found it yet...

To summarize:  I believe there is an additional GET associated with each POST,
and sometimes there are two GETs (see correction above).

Comment 12

[Andrew Schultz]

If I take your html from the first attachment, (point it at a valid page), load
it and submit it, I get 1 POST.  So the problem is between Mozilla and your
server or server app.

> I don´t see this in builds some days older or some days newer.

So you're not seeing the same bug, since he reported the problem with Firefox 1.0.

Comment 13

[Jon]

We are having the same issue where for each POST request in FIREFOX, after 
successful POST, it sends 1 more GET request.   From reading the logs posted 
already, sounds like a known issue with Mozilla FireFox.   Is there any 
expected date for a new release of the product in the near future to correct 
this issue?   

Comment 14

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 15

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.