Browser rePOSTS data after 5 minutes if no headers are received




Networking: HTTP
15 years ago
4 years ago


(Reporter: michael kimsal, Assigned: Darin Fisher)



Firefox Tracking Flags

(Not tracked)




15 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021126
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021126

I have a mail utility which queues 1000s of emails for delivery.  It may take
10-15 minutes to send back results, but Mozilla will rePOST the query after a
bit over 5 minutes if nothing is sent back.  This is horrendous and has caused
many people to get duplicate emails.  This is NOT just the Mozilla 1.3beta I'm
using - this happened last August or so, with whatever Mozilla was current then,
and *probably* happened from the Windows version, not Linux.

Log file dump... - q [11/Mar/2003:17:40:16 -0500] "POST /herc/main.php/email
HTTP/1.1" 200 - - q [11/Mar/2003:17:45:18 -0500] "POST /herc/main.php/email
HTTP/1.1" 200 - - q [11/Mar/2003:17:50:20 -0500] "POST /herc/main.php/email
HTTP/1.1" 200 - - q [11/Mar/2003:17:55:22 -0500] "POST /herc/main.php/email
HTTP/1.1" 200 - - q [11/Mar/2003:18:00:24 -0500] "POST /herc/main.php/email
HTTP/1.1" 200 - - q [11/Mar/2003:18:05:26 -0500] "POST /herc/main.php/email
HTTP/1.1" 200 - - q [11/Mar/2003:18:11:25 -0500] "POST /herc/main.php/email
HTTP/1.1" 200 - - q [11/Mar/2003:18:16:27 -0500] "POST /herc/main.php/email
HTTP/1.1" 200 - - q [11/Mar/2003:18:21:29 -0500] "POST /herc/main.php/email
HTTP/1.1" 200 - - q [11/Mar/2003:18:26:31 -0500] "POST /herc/main.php/email
HTTP/1.1" 200 - - q [11/Mar/2003:18:31:33 -0500] "POST /herc/main.php/email
HTTP/1.1" 200 - - q [11/Mar/2003:18:36:35 -0500] "POST /herc/main.php/email
HTTP/1.1" 200 - - q [11/Mar/2003:18:41:37 -0500] "POST /herc/main.php/email
HTTP/1.1" 200 - - q [11/Mar/2003:18:46:39 -0500] "POST /herc/main.php/email
HTTP/1.1" 200 -

Reproducible: Always

Steps to Reproduce:
1.  POST to a page which takes 5-10 minutes to come back
2.  Wait
3.  Watch log files for reposted requests

Actual Results:  
requests rePOsted

Expected Results:  
Not reposted
darin, don't you have a bug on this already?
Assignee: asa → darin
Component: Browser-General → Networking: HTTP
QA Contact: asa → httpqa
Whiteboard: DUPEME

Comment 2

15 years ago
reporter: sounds like the connection is getting dropped.  this code was recently
changed around a bit for 1.3 beta.  we will re-issue the POST request sent over
a re-used connection if the connection closes and we haven't received any data
from the server.  this is the same behavior as netscape 4.x.  please test only
with mozilla 1.3 beta.  the older versions of mozilla would resend the request
even if a newly created connection was closed.

Comment 3

15 years ago
I searched and couldn't find anything on this, but it's so bizarre I'm sure I
wasn't using the correct 'words' ('repost' didn't bring back anything, for example)

The connection is most certainly *not* going down, as I am continually using it
downloading other things and such.  Perhaps Mozilla automatically *drops* the
connection after a set time period and retries?  The timing is very repetitive -
per the log file I put up there, it's always 5 minutes and a few seconds - too
repetitive to say it's a dropped connection.  

Comment 4

15 years ago
What I don't get is why you rePOST something without asking?  I can't even go
forward or back in (what should be) my local cache to POSTed pages without
warnings popping up, yet Mozilla will *silently* rePOST stuff?  Are you saying
this is a known bug, or this is behaviour Mozilla developers intended?

Comment 5

15 years ago
the OS of the client machine may also be dropping the connection.  can you
capture a packet trace using ethereal ( or some other tool? 
that will give us more information about what is going on.

the repost is by design, and it is required when posting over a keep-alive
connection.  given the way TCP/IP works, you can't avoid the fact that you might
be writing to a connection that has just been closed by the server.  you will
only discover that it is closed once you start to read from the connection. 
since the server can close keep-alive connections at any time after the first
response, a useragent must retry the request on a new connection if it discovers
the connection closed without any respones to its subsequent request.  this
implementation is very standard.

can you please provide more information about what version of mozilla you are
testing?  thx!
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:
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.
Last Resolved: 13 years ago
Resolution: --- → EXPIRED


4 years ago
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.