curl uses POST for all requests after redirect - http

According to the documentation and some similar questions on SO curl should follow a redirect using GET method, unless --post30x is specified as a parameter. However that's the result of my testing
curl -kvv -b /tmp/tmp.BEo6w3GKDq -c /tmp/tmp.BEo6w3GKDq -X POST -H "Accept: application/json" -L https://localhost/api/v1/resource
> POST /api/v1/resource HTTP/1.1
> User-Agent: curl/7.29.0
> Host: localhost
> Cookie: JSESSIONIDSSO=AB59F2FD09D38EDBAACB726CF212EA2E; JSESSIONID=743FD68B520840094B6D283A81CF3CFA
> Accept: application/json
>
< HTTP/1.1 302 Found
< Server: Apache-Coyote/1.1
< Strict-Transport-Security: max-age=15768000; includeSubDomains
< Cache-control: no-cache, no-store
< Pragma: no-cache
< Location: https://testserver.int/api/v1/resource
< Content-Length: 0
< Date: Fri, 27 Jan 2017 08:41:05 GMT
<
> POST /api/v1/resource HTTP/1.1
> User-Agent: curl/7.29.0
> Host: testserver.int
> Cookie: JSESSIONID=1tcxpkul4qyqh1hycpf9insei9
> Accept: application/json
I would expect the second request to actually be using GET instead of POST.
curl's man page says:
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. If the response code was any
other 3xx code, curl will re-send the following request using the same
unmodified method.
You can tell curl to not change the non-GET request method to GET
after a 30x response by using the dedicated options for that:
--post301, --post302 and --post303.
Unfortunatelly that's not what I'm seeing and there is no option for --get30x.
So my question is - how to make curl follow a redirect response (301/302/303) with a GET request to the Location as it is written in the documentation?
I've tested it with curl/7.29.0 as well as curl/7.50.3.

Problem: You are telling curl to do that with your use of -X POST. As the man page section for -X explains this:
The method string you set with -X, --request will be used for all requests, which
if you for example use -L, --location may cause unintended side-effects when curl
doesn't change request method according to the HTTP 30x response codes - and
similar.
Fix: Remove the -X POST from your command line. Use -d "" instead to send an empty post that will adjust accordingly to the proper method after redirect.
More: Explanation and rant in my blog post unnecessary use of curl -X.

Related

Symfony Request::getContent(true) strange behaviour in wget but not curl

A user is able to upload a file. During the upload the file is scanned. If there is an issue with the file Symfony returns a Response(400) and the rest of the file is not uploaded, saving the user and the host time and bandwidth.
This is done via \Symfony\Component\HttpFoundation\Request::getContent(true)
$resource = $request->getContent(true);
The file is scanned a line at a time using:
fgets($resource);
The resource is also closed before the response is sent to the user:
fclose($resource);
However there is unexpected and strange behaviour happening for some user clients.
For example wget:
wget -4 --no-check-certificate --method PUT --timeout=0 --header 'Authorization: Bearer xxx' --body-file='xxx' 'https://example.com/xxx' --content-on-error -d -O -
Response hangs:
---request begin---
PUT /xxx HTTP/1.1
User-Agent: Wget/1.20.3 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: xxx
Connection: Keep-Alive
Content-Length: 37767602
Authorization: Bearer xxx
---request end---
[writing BODY file xxx ...
It appears that wget does not understand the upload does not need to be completed, is this a header that php is failing to send or a flag required in the wget command?
A similar command in curl works
curl -k --location --request PUT 'https://example.com/xxx' \
--header 'Authorization: Bearer xxx' \
--data-binary '#/xxx'
Response
< Server: Apache/2.4.38 (Debian)
< Vary: Authorization
< X-Robots-Tag: noindex
< Transfer-Encoding: chunked
* HTTP error before end of send, stop sending
<
* Closing connection 0
* TLSv1.3 (OUT), TLS alert, close notify (256):

Server utility: receive HTTPS POST requests, cat the data

To test something, I want to run a simple web server that:
Will listen for HTTPS POST requests
Print the POST data received to STDOUT (along with other stuff, potentially, so it's fine if it just cats the whole HTTP request)
Is there a quick way to set something like this up? I've tried using OpenSSL's s_server, but it only seems to want to respond to GET requests.
Since s_server does not support POST requests, you should use socat instead of openssl s_server:
# socat -v OPENSSL-LISTEN:443,cert=mycert.pem,key=key.pem,verify=0,fork 'SYSTEM:/bin/echo HTTP/1.1 200 OK;/bin/echo;/bin/echo this-is-the-content-of-the-http-answer'
Here are essential parameters:
fork: to loop for many requests
-v: to display the POST data (and other stuff) to STDOUT
verify=0: do not ask for mutual authentication
Now, here is an example:
We use the following POST request:
% wget -O - --post-data=abcdef --no-check-certificate https://localhost/
[...]
this-is-the-content-of-the-http-answer
We see the following socat output:
# socat -v OPENSSL-LISTEN:443,cert=mycert.crt,key=key.pem,verify=0,fork 'SYSTEM:/bin/echo HTTP/1.1 200 OK;/bin/echo;/bin/echo this-is-the-content-of-the-http-answer'
> 2017/08/05 03:13:04.346890 length=212 from=0 to=211
POST / HTTP/1.1\r
User-Agent: Wget/1.19.1 (freebsd10.3)\r
Accept: */*\r
Accept-Encoding: identity\r
Host: localhost:443\r
Connection: Keep-Alive\r
Content-Type: application/x-www-form-urlencoded\r
Content-Length: 6\r
\r
< 2017/08/05 03:13:04.350299 length=16 from=0 to=15
HTTP/1.1 200 OK
> 2017/08/05 03:13:04.350516 length=6 from=212 to=217
abcdef< 2017/08/05 03:13:04.351549 length=1 from=16 to=16
< 2017/08/05 03:13:04.353019 length=39 from=17 to=55
this-is-the-content-of-the-http-answer

format of data for a http POST resquest when using the curl command

If I issue a curl command to a REST api then I get the response below.
curl -i http://10.4.0.22:8088/api/clients/TEST_1/8194/1/1
Response:
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 51
Server: Jetty(9.1.z-SNAPSHOT)
{"status":"CONTENT","content":{"id":1,"value":"0"}}
My understanding that this is equivalent to a http GET request.
What I'm trying to do is update the value field and change the value to 1.
I think this requires a POST request using the -d flag.
My question is how do I know what format the data should be in the curl command?
I tried
curl -d "{"status":"CONTENT","content":{"id":1,"value":"1"}}" http://10.4.0.22:8088/api/clients/EST_1/8194/1/1
but I get this response.
{"status":"METHOD_NOT_ALLOWED"}
I think the way that I am specifying the json after te -d flag is incorrect?
The response METHOD_NOT_ALLOWED means the server doesn't allow POST method.
You can add a -v to get a verbose output of the response. Sometimes the server responds back in the message as to what HTTP Methods (or Verbs) it allows.
I tried your parameters on my application endpoint and it worked. see below
curl -d "{"status":"CONTENT","content":{"id":1,"value":"1"}}" http://sitename.azurewebsites.net/index.php -v
* Adding handle: conn: 0x2c257d0
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x2c257d0) send_pipe: 1, recv_pipe: 0
* About to connect() to sitename.azurewebsites.net port 80 (#0)
* Trying 104.211.224.252...
* Connected to sitename.azurewebsites.net (104.211.224.252) port 80 (#0)
> POST /index.php HTTP/1.1
> User-Agent: curl/7.33.0
> Host: sitename.azurewebsites.net
> Accept: */*
> Content-Length: 39
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 39 out of 39 bytes
< HTTP/1.1 200 OK
< Content-Length: 0
< Content-Type: text/html
< X-Powered-By: PHP/5.4.45
< Date: Fri, 04 Aug 2017 14:24:08 GMT
You can also try to specify the Content-Type header in your request and set it to corresponding Mime value.
For CURL, you can use the -H with the value set to "Content-Type: application/json"
Have you seen this thread: How to POST JSON data with Curl from Terminal/Commandline to Test Spring REST?

How to send a POST request using HTTPie?

I have a basic silex application, and I try to test it using HTTPie. Yet when posting using:
http POST http://localhost:1337 data="hello world"
The data, that I get from the Request object via:
$data = $request->request->get('data');
will always be empty. What is the problem here?
It was an httpie usage problem as the form flag was necessary, as silex requires the parameters to be form-encoded, yet the default of HTTPie is to pass a JSON object.
$ http --form POST http://localhost:1337 data="hello world"
HTTP/1.1 200 OK
Cache-Control: no-cache
Connection: close
Content-Type: application/json
Date: Wed, 14 Oct 2015 15:04:09 GMT
Host: localhost:1337
X-Powered-By: PHP/5.5.9-1ubuntu4.13
{
"message": "hello world"
}
Just to clarify what kOpernikus said, when you are making a POST request using httpie, use the following syntax:
http --form post :3000/register username="gilbert" password="stackoverflow!"
Alternatively, since forms are for post requests you can leave out post and also abbreviate --form to -f like so:
http -f :3000/register username=gilbert password=stackoverflow!
EDIT (thanks to Aerials)
To pass csrf token as header in the post request do:
http --form POST http://localhost:8000/login/ username=user password=pass X-CSRFToken:assQ$%auxASDLSIAJSd

HTTP language representation

In the HTTP language, the following lines expresses a GET request on a collection of articles:
GET /articles HTTP/1.1
Accept: application/json; level=1
Host: example.com
However, in this language, how can we express a request through a POST with its data? Is there an official spec? Thank you.
Edit
Using curl, a such request could be:
curl -H 'Accept: application/json; level=1' \
-X POST \
-d '<json>' \
http://example.com/articles
...where <json> could be:
{
"article": {
"title": "foo"
}
}
This example can be a POST with an empty body since your request is composed only of HTTP headers. But I don't recommend this.
You can read about HTTP in the RFC

Resources