Closed
Bug 156686
Opened 23 years ago
Closed 13 years ago
redirect on HTTP PUT publish gives a GET request
Categories
(Core :: Networking: HTTP, defect)
Core
Networking: HTTP
Tracking
()
RESOLVED
DUPLICATE
of bug 598304
People
(Reporter: jr, Unassigned)
References
Details
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.
Comment 1•23 years ago
|
||
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....
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•23 years ago
|
||
Is there a real site setup that I could test this with and QA could use for
verification?
BZ--is this a bug or ?
OS: Linux → All
Hardware: Macintosh → All
Comment 3•23 years ago
|
||
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).
Assignee: syd → darin
Component: Editor: Composer → Networking: HTTP
QA Contact: sujay → tever
Reporter | ||
Comment 4•23 years ago
|
||
> 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.
Comment 5•23 years ago
|
||
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.
Comment 6•23 years ago
|
||
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).
Comment 7•22 years ago
|
||
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.
Depends on: 48202
Target Milestone: --- → Future
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!
Reporter | ||
Comment 9•22 years ago
|
||
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/4.0.4.3
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.
Comment 10•22 years ago
|
||
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?
Comment 11•22 years ago
|
||
What did ns4 do for the POST version of this with a 302?
What does IE do for POST/PUT ?
Comment 12•19 years ago
|
||
RFC2616 is very clear about this (because there were problems with implementors' interpretation of text in previous specs).
There are two aspects to be considered;
a) whether the method should be preserved or changed to 'GET' upon a redirect
b) whether the user should be informed of a redirect on a non-GET (or HEAD) method
301, 302 and 307 all preserve the method, and require permission from the user before redirecting a non GET request.
303 changes the method to GET, and does not inform the user.
For tests, see:
http://www.mnot.net/javascript/xmlhttprequest/
("Redirects"). Be sure to follow the instructions.
For Firefox 1.5.01 on OSX, I see that the method isn't preserved correctly on non-GET 301's and 302's, and the user is never informed for non-GET requests (at least with XmlHttpRequest, which is the focus of those tests).
Comment 13•19 years ago
|
||
(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.
Updated•19 years ago
|
Assignee: darin → nobody
QA Contact: tever → networking.http
Target Milestone: Future → ---
Comment 14•13 years ago
|
||
There's a newer bug on this -- 598304 -- on which I already started work. Mark this one as duplicate?
Updated•13 years ago
|
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•