281634 - Reloading a GET request that was a 301 redirect from a POST request should not re-submit POST request

Status: RESOLVED EXPIRED

(Firefox :: General, defect)

Description

[Timwi]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.5) Gecko/20041110 Firefox/1.0 StumbleUpon/1.999
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.5) Gecko/20041110 Firefox/1.0 StumbleUpon/1.999

.

Reproducible: Always

Steps to Reproduce:
1. Write a small script (Perl, PHP, whatever) or find a website which accepts a
POST request, and replies to it with a 301 redirect.
2. Submit said POST request in Firefox, and wait for it to finish loading the
page you were redirected to.
3. Press Reload.
Actual Results:  
Firefox asks if you want to re-submit the POST data. If you choose "OK", it will
actually do that. If you click "Cancel", it won't reload.

Expected Results:  
It should reload the page just like any other GET request.

Comment 1

[Ben Fowler]

Are you sure that a 301 response to a POST request is considered good practice?

This comes up regrettably often on c.i.w.a.h and has its own page
http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html

Comment 2

[Timwi]

Wow. Thanks a lot for that link. Very useful indeed.

Looks like
1) I should change my script to use 303 instead
2) Firefox should think about redirecting to a POST request when it gets 301

Comment 3

[Terry Johnson]

I have the same problem with HTTP 303 "See Other" redirects on secure pages,
having implemented them after reading the article mentioned above:

Browser: Firefox 1.0.3, Server Apache 1.3 / PHP 4.3.10

Actual Behavior
- Refreshing the redirected page causes the form on the previous page to be
resubmitted.
- Using 'Back' and then 'Forward' causes the form on the previous page to be
resubmitted.

Expected Behaviour:
- Refreshing the redirected page should not cause the form to be resumbitted,
and should repeat the GET request indicated in the original 303 response.
- Using 'Back' and then 'Forward' should not cause the form to be resubmitted,
but may repeat the GET request if the redirected page is not cached.

The only way to resumbit the form should be to use 'Back' and then use the
submit control on the form.  The form page itself may have been sent with
no-cache headers if the intent is that by submitting the form, that instance of
the form is invalidated and should never be used again - for example a login
form containing a one-time token.

If the user goes 'Back' they will not be able to go 'Forward' again without
resubmitting the form, and they may thus lose data, or trigger an unintended
user-site interaction.  The intent of the HTTP 1.1 specification is clearly to
prevent that situation from arising.

I can produce a test case if the above is not sufficiently clear.

Comment 4

[Ben Fowler]

(In reply to comment #3)
> I can produce a test case ...

Almost certainly you should submit a test case: An engineer working on your
proposal would need to frequently check the observed behaviour against
what you expect.

Comment 5

[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 6

[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.