Seemingly incorrect relocation after HTTP/1.1 302 Found #4859
I came upon a strange behavior of relocation. I believe it to be a bug, as this behavior seems to contradict the one described in the manual, as well as the debug print of curl itself.
I did this
Issued a HTTP/1.1 PUT request with
curl redid the request to the new location with the following debug print:
I expected the following
As per curl's manpage in Debian,
Also, the debug print line:
I have expected a GET request to be made. However, a PUT request was made with
Got the same with
Debian unstable as of 2020-01-28 03:15:57-05:00
The text was updated successfully, but these errors were encountered:
You're not telling us the whole story. You started saying you used
Further down you then say "a PUT request was made", which implies you used more options to get that effect but didn't tell us how.
OK; I've explicitly ordered PUT with
By "a PUT request was made" I meant "curl made a PUT request", see the curl's debug print.
The full command line was
Configuration file contains only directives to set the client's SSL certificate.
While I agree that curl's behavior is consistent with RFC 7231, it is completely different from what is written in the manpage, which tells that curl responds to HTTP 302 with GET no matter which method was used before.
Not from generic non-GET to GET. Ref: #4859
There's no HTTP redirect response code to tell a client to change from PUT to GET. A client that sends a PUT should sent a PUT again after a 302 when following a redirect. If the server doesn't want/support this, then it should probably not redirect the PUT to begin with!