If http://publish.example.com/foo is set to redirect to http://www.example.com/cgi-bin/my-put-script/foo the first request (to publish.example.com) is a PUT but the request to www.example.com is a GET.
All the redirection methods in RFC 2616 say: If the 3xx 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. So we should not be redirecting at all here, methinks....
Is there a real site setup that I could test this with and QA could use for verification? BZ--is this a bug or ?
If the behavior is as reporter describes, this would be a bug in the HTTP code, which triggers a redirect unconditionally. We should be prompting for user permission to redirect. Not sure whether the redirected request should still be a GET or be a PUT (the HTTP spec seems a bit unclear on this).
> Is there a real site setup that I could test this with and QA > could use for verification? Publish a page to testbed3.jriddell.org and it will be redirected to testbed1.jriddell.org/cgi-bin/put/filename.html A GET will be send on the second request and the publish will fail (see testbed1.jriddell.org/putlog). Publishing directly to testbed1.jriddell.org/cgi-bin/put will (should) succeed.
the problem is, browsers have always automatically redirected from POST to GET. that has come to be expected. for PUT maybe we should change that.
here's the passage from RFC2616 section 10.3.3 on 302 redirects: 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. despite this, mozilla still fails to implement 307 correctly (see bug 48202).
marking as dependent on bug 48202. maybe this should even be a duplicate. not sure yet if we want to change our behavior for redirects other than 307.
Jonathan: Now that bug 48202 is fixed, can you please try this bug in recent trunk builds? (I tried, but looks like http://publish.example.com/foo is down). thanks!
Testing with build 2003032809 shows no change in behaviour The headers that are being replied to mozilla are HTTP/1.1 302 Found Date: Sun, 30 Mar 2003 00:08:58 GMT Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) mod_ssl/2.8.11 OpenSSL/0.9.6b PHP/4.0.6 FrontPage/220.127.116.11 Location: http://www.example.com/cgi-bin/put/blah.html Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1 Mozilla then sends the following request to the URL where it was redirected GET / HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030322 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,vid eo/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive and no body. Netscape 4 sucessfully redirected with a PUT and the document being sent.
suresh: perhaps it would make sense for our 302 behavior to preserve the method in all cases except POST. i know that sounds a bit inconsistent, but i'm worried about breaking compatibility with sites that depend on the non-standard behavior of existing browsers. bbaetz: any thoughts on this?
What did ns4 do for the POST version of this with a 302? What does IE do for POST/PUT ?
(In reply to comment #12) BTW, (b) is security-related; HTTP places those requirements on clients so that users stay in control of their actions.
There's a newer bug on this -- 598304 -- on which I already started work. Mark this one as duplicate?