Open
Bug 220368
Opened 22 years ago
Updated 3 years ago
Form gets submitted again after a redirection if the page is refreshed
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
NEW
People
(Reporter: amla70, Unassigned)
References
()
Details
(Keywords: helpwanted)
in the url there are three pages, all very simple.
in a.asp there's just a form submitted to b.asp
if a checkbox is checked in a, then b.asp shows a message and refresing b.asp (a
POSTDATA warning appears) redirects to c.asp (1)
if the checkbox is cleared then b.asp just redirect to c.asp (2)
in (2), if we refresh the page nothing happens, everything is fine.
But if we refresh c.asp in (1) then _the form is submitted again_, we go back to
b.asp and refreshing it again we end up in c.asp
tested in Mozilla 1.5RC1 WindowsXP. In IE 6.0 it doesn't resubmit except when we
reload b.asp
code of the pages (without the comments):
a.asp:
<%@ Language=VBScript %>
<%option explicit%>
<html>
<head>
</head>
<body>
<form method="post" action="b.asp">
<input type="checkbox" name="pause" checked> Do a pause.<br>
<input type="submit">
</form>
<br>
times submited:
<%=session("times")%>
</body>
</html>
b.asp
<%@ Language=VBScript %>
<%option explicit%>
<%
dim t
t=session("times")
if (isempty(t)) then t=0
session("times")= t+1
if (request("pause")="on") then
if (session("pause")=1) then
session("pause")=0
response.redirect "c.asp"
else
session("pause")=1
response.write "paused, press reload."
response.end
end if
end if
response.redirect "c.asp"
%>
c.asp
<%@ Language=VBScript %>
<%option explicit%>
<html>
<head>
</head>
<body>
<br>
times submited:
<%=session("times")%>
<a href="a.asp">go to a.asp again</a>
</body>
</html>
|
||
Comment 1•22 years ago
|
||
taking
reporter.. how critical is this bug? i presume it shows up in some web
application you are developing or have encountered on the web/some-intranet?
Assignee: form-submission → darin
Target Milestone: --- → mozilla1.6alpha
|
Reporter | |
Comment 2•22 years ago
|
||
it's not really important for me, in normal operation it wont happen in my
application. I found it due to a bug in my app which forced me to debug that part.
But although my example it might be rarely found in the real world it might
appear in other places, although it wasn't possible to reproduce it.
|
|
||
Updated•22 years ago
|
Keywords: helpwanted
Target Milestone: mozilla1.6alpha → Future
|
|
||
Comment 3•22 years ago
|
||
It's not clear to me whether reloading the result of a redirect should reload
the redirect result or the original url we started loading... How exactly is
the redirect done?
|
|
||
Comment 4•22 years ago
|
||
>It's not clear to me whether reloading the result of a redirect should reload
>the redirect result or the original url we started loading... How exactly is
>the redirect done?
for temporary redirects (302, 303, 307) it probably makes sense to always start
with the original url. for permanent redirects (301) it is reasonable to do
link editing (per RFC 2616), meaning that we can reasonably just cut straight to
the final URL, and load that when the user presses reload.
now, i think as far as the URL bar is concerned, mozilla always updates the URL
with the final URL. i think that is common to all browsers. we may have a bug
on file about changing that to base it on the type of redirect as i have
described here.
|
|
Reporter | |
Comment 5•22 years ago
|
||
I don't know the code sent by IIS with the response.redirect that I use, but if
pressing reload after such a redirect would repost the original data then it
would be a mess for me as I use such workaround to avoid people reposting in our
forums if they press reload:
On a normal situation (number 2 in the report), the user post his message, I
process it and then do a redirect to the page that shows the data so that if he
press reload for whatever reason then the data isn't posted again. If now the
behaviour is changed so that the original page is submitted again I think that I
won't be the only one that will see this as a terrible regression.
|
|
||
Comment 6•22 years ago
|
||
The page uses a 302 redirect. From
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3:
10.3.3 302 Found
The requested resource resides temporarily under a different URI. Since the
redirection might be altered on occasion, the client SHOULD continue to use
the Request-URI for future requests. This response is only cacheable if
indicated by a Cache-Control or Expires header field.
Note the "SHOULD continues to use the Request-URI for future requests" part...
I think the problem here is that we _should_ reload "b" no matter what per this
rfc but so many pages rely on behavior 2 (because they just "redirect" without
realizing that many different types of redirects exist) that we hacked in
something like "don't put the redirecting page in history if we spent less than
1 second at it" or something along those lines. At least I recall
history/docshell code to that effect.
|
|
||
Updated•19 years ago
|
Assignee: darin → form-submission
QA Contact: ashshbhatt → ian
Target Milestone: Future → ---
|
||
Updated•16 years ago
|
Assignee: form-submission → nobody
QA Contact: ian → form-submission
|
Assignee | |
Updated•6 years ago
|
Component: HTML: Form Submission → DOM: Core & HTML
|
||
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•