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".
er, I meant to request that, not set it.
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.
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?
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?
-> reassign to default owner