I am trying to simulate this Curl command but only using C++:
curl -H "X-MBX-APIKEY: dummy_one" -X POST 'https://api.binance.com/api/v3/order?hello'
The above request generates this response:
{"code":-2014,"msg":"API-key format invalid."}
Curl's verbose logging switch shows it sent this:
> POST /api/v3/order?hello HTTP/2
> Host: api.binance.com
> user-agent: curl/7.81.0
> accept: */*
> x-mbx-apikey: dummy_one
>
This is my attempt in C++:
char* write_buf = "POST /api/v3/order HTTP/2\r\n"
"Host: api.binance.com\r\n"
"user-agent: curl/7.81.0\r\n"
"accept: */*\r\n"
"X-MBX-APIKEY: dummy_one\r\n"
"content-length: 5\r\n"
"content-type: application/x-www-form-urlencoded\r\n"
"hello";
if(BIO_write(bio, write_buf, strlen(write_buf)) <= 0)
{
However, my request is getting rejected with:
HTTP/1.1 505 HTTP Version Not Supported
After Googling I think this could be a generic error response, particularly with un-escaped spaces.
I'm not sure what is the exact problem.
My SSL connection is fine, it works perfectly with a GET request. The problem appears to be in the format of the POST request message.
This is HTTP/1.1. HTTP/2 is a binary protocol. Just change your /2 to /1.1 and you should get unstuck. HTTP/1.1 is not deprecated.
Curl verbose logging doesn't show the wire protocol, but rather just what it semantically sent.
Related
I'm trying to set the content-type header of my cURL request to application/json.
This is the request I'm using in cmd (I left out the Json-Body):
curl -v -X POST http://localhost:40071/api/Sale --header 'Content-Type: application/json' -d '{[Json Body]}'
When running this command, cURL is logging the following:
Note: Unnecessary use of -X or --request, POST is already inferred.
* Trying 127.0.0.1:40071...
* Connected to localhost (127.0.0.1) port 40071 (#0)
> POST /api/Sale HTTP/1.1
> Host: localhost:40071
> User-Agent: curl/7.79.1
> Accept: */*
> Content-Length: 332
> Content-Type: application/x-www-form-urlencoded
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 500 Internal Server Error
< Date: Tue, 09 Nov 2021 11:18:33 GMT
< Content-length: 0
<
My REST server is running into an exception because of HTTP 415 Unsupported Media Type.
It seems as if cURL did not make use of my "--header" parameter?
Because the log is showing that Content-Type: application/x-www-form-urlencoded was chosen.
I also tried it with the abbreviated parameter "-h".
Seems duplicate question, for more examples, refer here.
How to send a header using a HTTP request through a cURL call?
curl -X POST mockbin.org/request -H "Accept: application/json"
I make a POST request to REST API to upload a file. In Postman everything works fine. I add Basic authorization and custom CSRF (XSRF) token which I get from the server.
I want to make the same using cURL. I copied the code from Postman, and it does not seem to work.
I believe that the error is related to CSRF because if I turn off CSRF on server and make the same cURL call without CSRF token, everything works fine.
Now some more details:
That's what the command for cURL which Postman gives:
curl -X POST -H "XSRF: 79f51981-8e85-4e26-be1b-bf63aed92a42" -H "Authorization: Basic bbhjbjb=" -H "Cache-Control: no-cache" -H "Postman-Token: 76a7a43b-f407-15a2-aaff-5242b44d0f47" -H "Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW" -F "package=#C:\Downloads\hello-world.zip" "http://host:port/api/import"
And that's the reply I get with --verbose
timeout on name lookup is not supported
Trying ::1...
Connected to localhost (::1) port 7777 (#0)
POST /api/import HTTP/1.1
Host: localhost:7777
User-Agent: curl/7.47.1
Accept: /
XSRF: 79f51981-8e85-4e26-be1b-bf63aed92a42
Authorization: Basic bbhjbjb=
Cache-Control: no-cache
Postman-Token: 76a7a43b-f407-15a2-aaff-5242b44d0f47
Content-Length: 31281
Expect: 100-continue
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW;
boundary=------------------------742d3475ac5f6aba
< HTTP/1.1 302 Found
< Set-Cookie: JSESSIONID=1qfjmbntrthxll;Path=/api < Expires: Thu, 01 Jan 1970 00:00:00 GMT
< Set-Cookie: XSRF=b29bd143-cc80-49ad-b495-711125678o;Path=/;Expires=Thu, 15-Dec-2016 10:28:46 GMT
< XSRF: b29bd143-cc80-49ad-b495-711125678o < Location:
http://localhost:7777/api/login/error.jsp?errorMessage=Access Denied
< Content-Length: 0
< Server: Jetty(9.2.17.v20160517)
HTTP error before end of send, stop sending
Closing connection 0
I am probably missing something very obvious here, but don't know what yet.
Looks like I am redirected to login page, not being authenticated correctly, but do not know why (I do send XSRF in cURL). I tried also adding sessionid in cURL - also didn't work.
Any ideas and directions about where to search would be very appreciated!!!
As mentioned in this post, add following option
--cookie "csrftoken=XXXXXX;sessionid=YYYYYYY"
along with
-H "X-CSRFToken: XXXXX"
It is unclear how your server side code is implemented. One visible difference can be seen here is the UserAgent string in request header User-Agent: curl/7.47.1. You may try with adding -A "Mozilla/5.0" with your curl request.
About the comment above regarding XSRF 1-time token; Your server is returning Set-Cookie header in response. It can happen that the postman is using that as cookie for second time request, and that's why it works for it over and over. You can try adding -H "Cookie: XSRF=b29bd143-cc80-49ad-b495-711125678o" at the end of your curl and see if that makes any difference.
Those are all wild guess. Better you add some code at your server side that can print the request-headers. Then make two requests, one from curl and other one from postman. After that check the difference between the request headers. That will give you some clue.
In the end it turned out that the session id was required (adding JSESSIONID in cURL solved the problem).
Without more info on the server side code, I'm not sure either. If you're making your call from cURL, and not Postman, do you really need the Postman-Token header? Maybe it will work if you remove -H "Postman-Token: 76a7a43b-f407-15a2-aaff-5242b44d0f47" from the code.
curl -X POST \
-H "XSRF: 79f51981-8e85-4e26-be1b-bf63aed92a42" \
-H "Authorization: Basic bbhjbjb=" \
-H "Cache-Control: no-cache" \
-H "Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW" \
-F "package=#C:\Downloads\hello-world.zip" \
"http://host:port/api/import"
I have been reading multiple articles on how to sniff and subsequently use the data obtained to interact with closed source apis recently.
I am concentrated on the tinder api since it seemed to me ample research had been done already on it, hence it would be easy to learn from.
http://ttcubicle.blogspot.com/2015/03/reverse-engineering-tinders-api.html
http://ec2-52-42-144-243.us-west-2.compute.amazonaws.com/tinder/
Althrough I managed to sniff the authentification between the tinder app on my phone and the server through fiddler, I am not able to actually simulate that login using curl on the command line
----- Below is the request send from my phone to the server --- for obvious reasons I changed my actual data ----
POST https://api.gotinder.com/auth HTTP/1.1
platform: android
User-Agent: Tinder Android Version 6.5.1
os-version: 23
Facebook-ID: 10151935000326599
Accept-Language: en
app-version: 1955
Content-Type: application/json; charset=utf-8
Content-Length: 257
Host: api.gotinder.com
Connection: Keep-Alive
Accept-Encoding: gzip
X-Auth-Token: ccXX9a-4a99c-4e32-8154-9b21asf5eec
{"facebook_token":"EAfasfasfasfN6solZAh8M3kwxsP1JzF6OBDocdNUEyxd8tsVCN6kWZA6fArZB0T5dZArmdVvKAXUuQZCOtoVZBPasfzUMz9RfFoSpEifEVm7bAIspEerbLKRgW3DCpHHuxVyZApr1koAHhIjCGtxUZAAZAtDvTTbayrkF","facebook_id":"111111119","locale":"en"}
My knowledge regarding POST / Headers and all of these things is still a bit shacky (thats why I am trying to re-enact) but from what I understand that next step should be to send a POST request with curl that sends the X-Auth-Token in the header and facebook_token and so on in the data part.
something like this:
curl -H "Content-Type: application/json" -H "X-Auth-Token: cc5555a-499c-4e32-8154-9b25555ec" -d '{"facebook_token":"EAAGasdpsBAEzbJDJdcHXLjKpDjN6solZAh8M3kwxsP1JzF6OBDocdNUEyxd8tsVCN6kWZA6fArZB0T5dZArmdVvKAXUuQZCOtoVZBPZBMTUJzUMz9RfFoSpEifEVm7bAIspEerbLKRgW3DCpHHuxVyZApr1koAHhIjCGtxUZAAZA555TTbayrkF","facebook_id":"101519555326599","locale":"en"}' https://api.gotinder.com/auth
However, no matter how I change the parameters around, I always get Errorcodes 500 or 401 thrown back at me. The maximum I can get is the server telling me that it excpects a facebook_token (which is obviously send in the data section)
Does anyone has experience with this sort of problem ?
Thank you
I just discovered phyton and... holyshit i am in love!
payloadauth = {"facebook_token":"EAA xxxxxx
header1 = { 'platform': 'android','User-Agent': 'Tinder, 'X-Auth-Token':'cblabla
with requests.Session() as c:
response = c.post('https://api.gotinder.com/auth',data=payloadauth)
response = c.get('https://api.gotinder.com/recs/core?locale=en', headers=header1)
print(response.json())
four lines of code...
consider a web service written in play, which excepts POST request (for uploads). now, when testing this with a medium size image (~75K) I've found out a strange behaviour. well, code speaks more clearly than long explanations, so:
$ curl -vX POST localhost:9000/path/to/upload/API -H "Content-Type: image/jpeg" -d #/path/to/mascot.jpg
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 9000 (#0)
> POST /path/to/upload/API HTTP/1.1
> User-Agent: curl/7.35.0
> Host: localhost:9000
> Accept: */*
> Content-Type: image/jpeg
> Content-Length: 27442
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
< HTTP/1.1 200 OK
< Content-Type: application/json; charset=utf-8
< Content-Length: 16
<
* Connection #0 to host localhost left intact
{"success":true}
as you can see, curl decides to add the header Content-Length: 27442, but it's not true, the real size is 75211, and in play, I indeed got a body in size only 27442. of coarse, this is not the intended behaviour. so I tried a different tool, instead of curl I used the POST tool from libwww-perl:
cat /path/to/mascot.jpg | POST -uUsSeE -c image/jpeg http://localhost:9000/path/to/upload/API
POST http://localhost:9000/path/to/upload/API
User-Agent: lwp-request/6.03 libwww-perl/6.05
Content-Length: 75211
Content-Type: image/jpeg
200 OK
Content-Length: 16
Content-Type: application/json; charset=utf-8
Client-Date: Mon, 16 Jun 2014 09:21:00 GMT
Client-Peer: 127.0.0.1:9000
Client-Response-Num: 1
{"success":true}
this request succeeded. so I started to pay more attention to the differences between the tools. for starter: the Content-Length header was correct, but also, the Expect header was missing from the second try. I want the request to succeed either way. so the full list of headers as seen in play (via request.headers) is:
for curl:
ArrayBuffer((Content-Length,ArrayBuffer(27442)),
(Accept,ArrayBuffer(*/*)),
(Content-Type,ArrayBuffer(image/jpeg)),
(Expect,ArrayBuffer(100-continue)),
(User-Agent,ArrayBuffer(curl/7.35.0)),
(Host,ArrayBuffer(localhost:9000)))
for the libwww-perl POST:
ArrayBuffer((TE,ArrayBuffer(deflate,gzip;q=0.3)),
(Connection,ArrayBuffer(TE, close)),
(Content-Length,ArrayBuffer(75211)),
(Content-Type,ArrayBuffer(image/jpeg)),
(User-Agent,ArrayBuffer(lwp-request/6.03 libwww-perl/6.05)),
(Host,ArrayBuffer(localhost:9000)))
So my current thoughts are: the simpler perl tool used a single request, which is bad practice. the better way would be to wait for a 100 continue confirmation (especially if you gonna' upload a several GB of data...). curl would continue to send data until it receives a 200 OK or some bad request error code. So why play sends the 200 OK response without waiting for the next chunk? is it because curl specifies the wrong Content-Length? if it's wrong at all... (perhaps this refers to the size of the current chunk?).
so where's the problem lies? in curl or in the play webapp? and how do I fix it?
the problem was in my curl command. I used the -d argument, which is a short for --data or --data-ascii, when I should have used --data-binary argument.
I am using curl for sending a POST HTTP message to my server. At Server side I am opening a socket and reading the data by using following code
recv(socket_Fd, (void *)ucBuffer, (size_t)((sizeof(ucBuffer) - 1)), NULL);
I am able to get the header of the POST message but in message body I am getting only one line , rest are missing.
Data I am receiving at server end.
POST /info HTTP/1.1
User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
Host: 192.168.0.57:10000
Accept: */*
Content-Length: 356
Content-Type: application/x-www-form-urlencoded
Bhupesh Bhargava
In message header it's showing right content length but message body is missing. Any idea where I am doing wrong.
curl command I am using
curl --data-binary #/home/bhupesh/data_save2 http://192.168.0.57:10000/info
The curl command seems to be OK and if we go by the documentation here, the following should be true.
Data is posted in a similar manner as --data-ascii does, except that
newlines are preserved and conversions are never done.
So, this leaves us with the fact that there should be a problem in your Server implementation. It is not quite sure how you are getting the received stuff at the server, but you should be careful about sequencing what you receive by yourself. Here is an example how you could do that.