Closed Bug 137936 Opened 22 years ago Closed 21 years ago

POST operations will be executed twice instead of once

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 61363
Milestone:
mozilla1.1beta

People

(Reporter: ken_kizaki, Assigned: alexsavulov)

Details

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020415
BuildID:    2002041512

When Mozilla performs a POST operation (e.g Uploading, changing or deleting files via a web interface) it will execute this two times. this will cause nasty error messages since the file already has been changed or deleted by the first operation.

Reproducible: Always
Steps to Reproduce:
Best would be either a cgi or php script which performs file changes/ uploads. U will find them for instance on any web based e-mail account. Then delete a message. Works as well on messageboards and webinterfaces for filetransfers

Actual Results:  On renaming /deleting the script will display an error message. on file uploads it may result in two files uploaded (the second one renamed by the script to avoid overwriting).

Expected Results:  It should only perform it as many times as the user hits the submit button.

The Linux builds don't seem to be affected by that problem. It also occurs on the "official" 0.99 release.
to form submission
Assignee: Matti → alexsavulov
Component: Browser-General → Form Submission
QA Contact: imajes-qa → vladimire
reporter, does the page you get as a result of the form submission have a <meta
http-equiv="content-type"> tag that specifies charset?
It happens both with charset specified and if its not specified. Each time the bug occurs u will get two warning messages by Mozilla itself. 1st says that the page would contain POST data that will be resent if I continue. 2nd one starts the same but then continues that these data would have been expired from the cache. When u make a capture of the http headers sent out u can see that the post operation is repeated twice, hence the warning messages.
I confirm. happens all the time when I delete mail through yahoo.com's webmail
interface. It's actually been happening for a week or two.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Severity: normal → major
OS: Windows 2000 → All
It seems to depend on the server properties. A good example are the following two urls:
http://fud.prohost.org/forum/

http://www.rokopsecurity.de/forum/

Both run version 1.2.5 of the FUDforum however only the second url is affected by the POST problem. It does not happen on each post operation u come across, but once u found a server affected it can be always reproduced there. For instance at http://www.yahoo.com (as already mentioned)
Severity: major → normal
OS: All → Windows 2000
Severity: normal → major
OS: Windows 2000 → All
Meanwhile I made captures of the http responses from the servers and the result is really interesting:
At first the response of a server where the post operation works as expected:

+++RESP 1463+++
HTTP/1.1 200 OK
Date: Wed, 17 Apr 2002 11:10:45 GMT
Server: Apache
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Last-Modified: Wed, 17 Apr 2002 11:10:45 GMT
Cache-Control: no-cache, must-revalidate
Pragma: no-cache
Keep-Alive: timeout=10
Connection: Keep-Alive
Content-Type: text/html
Content-Encoding: gzip
Content-Length: 5552

And now compare it to the following examples of servers where this bug strikes:

+++RESP 1600+++
HTTP/1.1 200 OK
Date: Wed, 17 Apr 2002 11:32:32 GMT
Server: Apache/1.3.12 (Unix)  (Red Hat/Linux) PHP/4.0.3pl1 mod_ssl/2.6.3 OpenSSL/0.9.5a
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html

+++RESP 1400+++
HTTP/1.1 200 OK
Date: Wed, 17 Apr 2002 11:08:32 GMT
Server: Apache/1.3.20 (Linux/SuSE) mod_jk mod_ssl/2.8.4 OpenSSL/0.9.6b mod_python/2.7.5 Python/2.1.1 mod_perl/1.26 PHP/4.1.2 FrontPage/4.0.4.3
X-Powered-By: PHP/4.1.2
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Last-Modified: Wed, 17 Apr 2002 11:08:32 GMT
Cache-Control: no-cache, must-revalidate
Pragma: no-cache
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html

+++RESP 1533+++
HTTP/1.1 200 OK
Date: Wed, 17 Apr 2002 11:22:26 GMT
Server: Apache/1.3.19 (Unix)  (SuSE/Linux) FrontPage/4.0.4.3 mod_layout/1.0
mod_throttle/3.0 mod_fastcgi/2.2.2 mod_ssl/2.8.3 OpenSSL/0.9.6a PHP/4.0.6
mod_perl/1.25 mod_dtcl
X-Powered-By: PHP/4.0.6
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html

So to me it seems that whenever transfer encoding is set to "chunked" and the
content length isn't specified the bug seems to occur. Maybe a hint?
The stuff is very interesting. I have to correct my last post. In fact "chunked"
does work if the charset is added to the header:

+++RESP 32+++
HTTP/1.1 200 OK
Date: Wed, 17 Apr 2002 13:58:34 GMT
Server: Apache/2.0.35 (Win32)
X-Powered-By: PHP/4.1.2
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1

By the time I set no value for the charset in the php.ini it will result in the bug suddenly appearing. So it's actually an issue with Mozilla and the PHP
settings on the server. so a buggy configuration should look like in the
Examples above

Some more stuff:
Other blends of POST operations (aside from PHP) also seem to be affected if
the server does not specify the charset with the content type in the
http-header. Another nasty side effect I watched on an "Ultraboard" (a cgi-based
bulletin board):
When registerring as a new user the script will return an error saying the 
chosen name would already have been taken, though the process was sucessfully
finished. What makes it really nasty is, no matter what name u would choose it
always returns that the requested login already has been taken. Each post
submitted caused the message to be written twice, so I was forced to use a
different browser.
Checking my Yahoo account yesterday the error didn't appear this time. Here's the capture for it which explains why it worked this time.

+++RESP 3088+++
HTTP/1.0 200 OK
Date: Wed, 17 Apr 2002 20:13:52 GMT
P3P: policyref="http://p3p.yahoo.com/w3c/p3p.xml", CP="CAO DSP COR CUR ADM DEV
 TAI PSA PSD IVAi IVDi CONi TELo OTPi OUR DELi SAMi OTRi UNRi PUBi IND PHY ONL
 UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE GOV"
Expires: Sun, 06 Nov 1994 08:49:37 GMT
Pragma: no-cache
Cache-Control: private
Vary: Accept-Encoding
Connection: close
Content-Type: text/html
Content-Encoding: gzip
Content-length: 4983

This time content length was specified and encoding changed to "gzip" which made
Mozilla behave like any other browser in this situation.
Severity: major → critical
I'm not too sure about this.. but is 118219 another incarnation of this bug?
damn, i'm setting here a target but who knows if we shouldn't pay more attention
to this one. as soon as i'm done triaging, will come back to take a look.
Priority: -- → P1
Target Milestone: --- → mozilla1.1beta
I believe this bug also occurs for eBay auction submissions, though in that
case, the POSTDATA warning does come up.

(steps to reproduce): bid on an auction on any eBay page; note that a warning
will display indicating that POSTDATA will be resubmitted, but the original POST
went through.

This did not occur in RC1, but started in RC2 and is still present in RC3 (Mac
OS X,10.1.4)
is anything being done about this bug. It is still there in 2002061108 and
honestly, is one of hte biggest blockers to my using Moz. What if my credit card
gets charged twice during a routine payment online. 
Darin, the comments in here make this sound like a Networking thing ... what is
this chunked encoding thing?
in case you want to read about "Transfer-Encoding: chunked"

http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6

yeah, it probably would be good to look at a HTTP log for this problem.
Are we sure this isn't a dup of 105709, where charset autodetection being
enabled triggers the same symptoms?  That's a shocker, but at least it can be
worked around by disabling the autodetection.

I'm suspicious because of the original reporter's .jp e-mail address.
As I am quite new to PHP, I'm certainly not as proficient with development as 
clearly you others are,   However, I have just spent the better part of today 
wrestling with this problem, only to learn late in the day about this web 
site.  I have definitely confirmed this as a problem with NS 6.2.3. I 
consistently demonstrate two submits taking place.
Has anything happened with this bug?  I have gotten burned twice in the past
week with online purchases/reservations and I have had to go back to IE for
online banking.  I have seen this happen in Phoenix 0.3 and all Mozilla versions
up to and including 1.2a.
after reading through all the comments, i tend to agree that this sounds like a
problem with charset detection.  there are a couple triggers:

1) no charset specified; auto-detection enabled

2) charset specified using <meta HTTP-EQUIV="content-type" CONTENT="text/html;
charset=xxx>, and moz does not see this tag in the first chunk parsed.

either of these conditions will _unfortunately_ force a reload.
lovering priority due to low visibility
Priority: P1 → P2
Just happened to me again.  Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.3a) Gecko/20021207 Phoenix/0.5.  Silently posted the same online bill
payment twice.  No warnings or popups of any sort.
As in #1 report, the problem seems to occur still today
when uploading a file for web-based e-mail service to
add attachment file takes place.
And I got a strange error message from the service.

The bug seems to be triggered on and off due to the
server-side configuration changes as well.

I am using www.nifty.com e-mail service available through
its web interface, but for the last several weeks
the file attachment suddenly as stopped  working if I use
Mozilla under linux (or win98se). 
Old netscape 4.x on linux and win98se still works jsut fine.
So does IE 6 under win98se.
The attachment fature worked for the preceding few months if I 
recall correctly.

I thought of attaching the web transaction log (HTTP headers, etc.)
for examination by the people in the know,  
but it turns out the e-mail service is offered AFTER
SSL negotiation for https: access takes place, so all I got
after installing ethereal on win98se (at home) was
encrypted mumbo jumbo.

I have no idea IF SSL usage (https:) has anything to do with
this POST problem. There WERE discussions at a Japanese web forum
about the possibility of character autodetection mentioned
here, but the last
time I tried disabling it under linux, the uploading
still didn't work. (My memory is hazy though.)

In any case, for the last few weeks, I fire up old netscape 4.7x
to send an e-mail with attachment: I would say this bug is not
low visibility and is very grave one for ordinary usage.

(Yes, I use mozilla to access Japanese Nifty e-mail service.)
ishikawa: what version of mozilla are you testing?
I am using 1.4a under linux lately.
(But come to think of it, the 1.4a under wi98se also seems
to suffer from the same problem. Again, too bad, I can't take
a look at exact header lines since it is in SSL encrypted stream.
The reason I think the problem I encounted is POST twice problem
is the description in the previous post #1 and others, and also
posts I found on a Japanese web forum where similar problems were 
discussed.)


I wonder if this problem discussed here (137936) are related to

the bug #
  160144    
  112848

Anyway, another observation: 

I am using the webmail interface
at
	http://www.nifty.com

(a large Japanese ISP.).

Since the webmail service is offered using https: (after
username/password are entered), I can't read the
http headers passed in the communication using
packet snooper such as etheral. So the paragraph
below is again a pure guesstimate.

But I noticed that mozilla 1.4a has a high failure rate of
posting the e-mail: when I hit submit (send) button, I often
receive (Page Contans No Data) message. If this happens,
then repeating the procedure won't cure the problem.
Again, if I switch to, say, netscape 4.80 (under linux) and
try the same procedure, the sending of e-mail works using
the web interface works like a charm.

Even if I admit that the server may have overload problem
at peak time or something,
the pure high rate of failure on mozilla side and
that netscape handling the same chore at about the same time
of the day right on the same PC under the same OS,
seems to suggest that there is a problem or two in POST processing of mozilla.
The netscape windows were opened right next to mozilla in these
situations.
(This problem is also observed under win98se as well as under linux.)

Now I have a feature question related to debugging this problem.

Is there any undocumented feature of Mozilla which permits me
to take a look at the headers (and headers only)
of the HTTP inquiries issued and results received by mozilla
even if the HTTP inquiries are embedded in SSL connection, 
i.e., https: connection?

Such a feature of mozilla, which knows the issued header lines and
received header lines will be very valuable in diagnosing what is
causing this problem I observe in relation to some of the observations
which other people made about about particular header lines in the
response.

I would think  showing the request header lines of each
request and response stored in a ring buffer (maybe 64K is large
enough.) would go a long way. These ought to be available even
inside https: connection.  Also, the feature should be available
to end-user as well so that a useful information can be sent to
developers.

I wonder how the dump in the comment #6-#8 are obtained.
Aren't communications to yahoo.com mail service encyrpted? 
(Oh wait, #6 is not from yahoo, and it seems to say
that OpenSSL in resp 1600 case. Interesting.)

Should I submit a separate feature request if such a request is
accepted to bugzilla? Or is there a different venue for
such a feature request. Granted, this is not a typical end
user request, but a feature that would help developers a lot in that
end user would be able to send useful information when a bug
strikes.
 
If such a feature is already available, please let me know how I can
enable that.

PS: I did notice that when the problem occurs today
one of the conditions mentioned in comment #18
was met:

>2) charset specified using <meta HTTP-EQUIV="content-type" CONTENT="text/html;
>charset=xxx>, and moz does not see this tag in the first chunk parsed.

But I have no control over what the
server sends me (right?) :-(
So we are at the whim of the server operators, and
specifying the charset is not such a evil thing, I think.

ishikawa san.

You can get log by seting environment variables.

NSPR_LOG_MODULES=nsHttp:5
NSPR_LOG_FILE=http.log

An Exapmle.
http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=2678
That page is written in Japanese.
But You and I are Japanese.

I think I found a different bug on my way to
find out why uploading of attachment file fails
using Nifty's webmail access page.
So I filed a different bug report. :
http://bugzilla.mozilla.org/show_bug.cgi?id=204085

POST is not properly retried when the server request
Authentication info. It could be that the POST-twice bug
might have been fixed in the latest 1.4a, but somehow
the necessary retry is no longer done for the authentication case.

Anyway, thank you Mihara-san, for the tips regarding
logging. That was invaluable.

Now I don't know if my original problem is POST-twice problem
or POST-not-retried-when-authentication-is-required.


The problem I filed for Bug 204085 was eventually solved
by making mozilla RFC compliance better for domain validation for
authentication purposes.

I am using the nightly build:
(Using . Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030520)

Bug 141702 was the main entry for this
particular bug.

So, my not being able to upload the
file as attachment to a webmail interface
seems to be solved by this obscure bug fix.

>Now I don't know if my original problem is POST-twice problem
>or POST-not-retried-when-authentication-is-required.

It looks the bug I had with Nifty webmail is caused by
the latter.
If I find the problem again (the bug was
intermittant in the sense that by the timing of
pressing buttons, sometimes the problem was solved!?)
AND find that the current mozilla seems to issue
POST twice, then I will revisit this bug.

Presumably, the post-twice bugs were real
for the reporters who filed bug entries here and
so hopefully in the future revisions, that bug is
fixed. The log files produced by the
environmental trick mentioned in the few articles back
were immensely helpful.
So now I am leaving the logging permanently on.
I will get about 1-3Mb of log for a short session for my usage.
YMMV.





Confirm that this is still happening, now in firebird.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030526 Mozilla Firebird/0.6

Here's my response header from the post action:



16386[80b7a90]: http response [
16386[80b7a90]:   HTTP/1.1 200 OK
16386[80b7a90]:   Server: Resin/2.1.4
16386[80b7a90]:   Cache-Control: private
16386[80b7a90]:   Content-Language: en-US
16386[80b7a90]:   Content-Type: text/html; charset=8859_1
16386[80b7a90]:   Transfer-Encoding: chunked
16386[80b7a90]:   Date: Wed, 16 Jul 2003 13:07:31 GMT
16386[80b7a90]: ]


*** This bug has been marked as a duplicate of 61363 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.