If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Firefox offers to re-send POSTed content to a redirected (302) URL

RESOLVED INCOMPLETE

Status

()

Core
Networking: HTTP
--
critical
RESOLVED INCOMPLETE
12 years ago
2 years ago

People

(Reporter: justdave, Unassigned)

Tracking

1.8 Branch
PowerPC
Mac OS X
Points:
---
Bug Flags:
blocking1.8rc1 -

Firefox Tracking Flags

(Not tracked)

Details

Many web sites issue a 302 redirect to a static HTML page after processing form
data when you submit a form.  Recently, Firefox started prompting to ask if I
wanted to re-send the data to the redirected URL.  The only choices given are
"Yes" and "Cancel".  Choosing "Cancel" STOPs the redirect, and you wind up with
the entity body of the 302 message with the "click here" link in it, IF the
server provides a useful entity body.

*Technically* this is in line with the RFC.  This was the original intent of
302.  In reality, no other browser expects it to work this way, and in fact, the
more recent revisions of the HTTP RFC actually added the 303 and 307 response
codes to stop being ambiguous about it because nobody did it right.

Having this dialog is a detriment to the user experience.  Your average Joe User
is not going to know what the heck it means, and since web developers don't
expect the POST content to get redirected (no existing browser in common use
does it), it stands a good chance of breaking sites if the user picks the wrong
option.  We should only be doing this on a 307 response, which is an explicit
request to forward the content.

See http://www.ietf.org/rfc/rfc2616.txt section 10.3.3

-----8<-----

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.

   The temporary URI SHOULD be given by the Location field in the
   response. Unless the request method was HEAD, the entity of the
   response SHOULD contain a short hypertext note with a hyperlink to
   the new URI(s).

   If the 302 status code is received in response to a request other
   than GET or HEAD, the user agent MUST NOT automatically redirect the
   request unless it can be confirmed by the user, since this might
   change the conditions under which the request was issued.

      Note: RFC 1945 and RFC 2068 specify that the client is not allowed
      to change the method on the redirected request.  However, most
      existing user agent implementations treat 302 as if it were a 303
      response, performing a GET on the Location field-value regardless
      of the original request method. The status codes 303 and 307 have
      been added for servers that wish to make unambiguously clear which
      kind of reaction is expected of the client.

-----8<-----

Pay particular attention to the Note: at the end.  "However, most existing user
agent implementations treat 302 as if it were a 303 response".
Flags: blocking1.8rc1+
Summary: Firefox offers to re-send POSTed content to a redirected URL → Firefox offers to re-send POSTed content to a redirected (302) URL
er, I meant to request that, not set it.
Flags: blocking1.8rc1+ → blocking1.8rc1?
If this dialog stays for 302 request, at a bare minimum we need to add an
additional button for "No" which follows the redirect and DOESN'T forward the
POST content, and add language to the dialog indicating that most sites probably
want you to hit No.

Updated

12 years ago
Assignee: nobody → darin
Component: General → Networking: HTTP
Product: Firefox → Core
QA Contact: general → networking.http
Version: 1.5 Branch → 1.8 Branch

Comment 3

12 years ago
Dave, is this also a bug in Firefox 1.0.x?
Dave, can you set up a test server (or point to a real-world example) so we can
regression test and see when this started showing up?
As far as I can tell, this behavior has been around since bug 48202, but only
for 307 redirects.
(http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp#2072
, which calls PromptTempRedirect which displays the prompt) 

It seems to me like nothing relevant has changed there recently. Do you have a
approximate regression range?

I'm assuming:
http://lxr.mozilla.org/seamonkey/source/netwerk/locales/en-US/necko.properties#60
is the exact string for the message you're seeing?

Updated

12 years ago
Flags: blocking1.8rc1? → blocking1.8rc1-
Asa: I'm not sure how much of an issue to make out of this.  Apparently others
on IRC aren't being able to reproduce it, and the one site I know where I can
trigger it at will is behind a port-forwarded SSL connection, which makes it
difficult to try to trace the network traffic to find out for sure what response
code is being sent back.  And if we want the Bugzilla upgrade this weekend to be
smooth, I'm not going to have time to try to track it down before then.  I was
just going to say to forget blocking...  since other people can't reproduce it
it's not worth holding anything for it.  Looks like you've already done so
though.  I'll attack it again next week when I have time to get something set up
to trace the response code being used.
(In reply to comment #5)
> I'm assuming:
> http://lxr.mozilla.org/seamonkey/source/netwerk/locales/en-US/necko.properties#60
> is the exact string for the message you're seeing?

Yes, that's the one. :)

If it's a 307 I'm getting sent, then the web app I'm hitting is probably broken
(I get the redirect prompt after uploading a new firmware image to the
out-of-band network management service on an HP server, and redirecting the
upload of a huge file just seems wrong :) )
justdave, I assume you can still see this?  Could you make an HTTP log using the directions at http://www.mozilla.org/projects/netlib/http/http-debugging.html and attach it here?

Comment 9

10 years ago
-> reassign to default owner
Assignee: darin.moz → nobody
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.