cURL / Mailing Lists / curl-library / Single Mail

curl-library

curl -X POST --location response 302 should do GET ?

From: Eric Favre <efavre_at_octo.com>
Date: Fri, 12 Feb 2016 16:34:24 +0100

Hello,

I have a question regarding the expected behavior of curl on a no-GET
request with a 302 response.
Here is what I read in curl's documentation about --location option:

--
When curl follows a redirect and the request is not a plain GET (for
example POST or PUT), it will do the following request with a GET if
the HTTP response was 301, 302, or 303.
--
Which makes sense, since it's the behavior of most browsers (even
though it's not what RFC1945 says).
However, this is not the behavior I observed on curl 7.43.0. To check,
I made a mock server with 3 simple services:
- 1 POST on /post_me_this that does a 302 on location /get_me_that
- 1 GET on /get_me_that which does a 200 with body
{"status":"ok","message":"disrespectful of HTTP ; respectful of doc"}
- 1 POST on /get_me_that which does a 200 with body
{"status":"ko","message":"respectful of HTTP ; disrespectful of doc"}
Here is what I get with a curl -L on my 1st mock:
$ curl -v --location --request POST
'http://private-f4bcd-ccuv1mocks2.apiary-mock.com/post_me_this'
//...
> POST /post_me_this HTTP/1.1
//...
< HTTP/1.1 302 Moved Temporarily
// ...
< Location: http://private-f4bcd-ccuv1mocks2.apiary-mock.com/get_me_that
// ...
* Issue another request to this URL:
'http://private-f4bcd-ccuv1mocks2.apiary-mock.com/get_me_that'
//...
> POST /get_me_that HTTP/1.1
//...
< HTTP/1.1 200 OK
// ...
{"status":"ko","message":"respectful of HTTP ; disrespectful of doc"}
So my question:
Am I misunderstanding something? Is this the intended behaviour, but
the documentation is outdated? Or is the documentation correct but the
library bugged?
Sorry if I missed the answer to that question somewhere.
Thanks!
Eric
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html
Received on 2016-02-12