In the code I inherited there is a REST call that sets up user permissions for a virtual host in a rabbitmq installation. On my developer box I have latest RabbitMQ server installed, 3.7.7. The client software uses a Spring RestTemplate to query the host. It generates a PUT request to http://localhost:15672/api/permissions/myhost/administrator with a payload of
{"read":".*","write":".*","configure":".*"}
and an HTTP header Content-Type:application/json;charset=UTF-8
This all looks reasonable to me - but the response is
HTTP/1.1 415 Unsupported Media Type
This code is years old, and I suspect it is my RabbitMQ installation that is too new for it, but I'd like to rather make the code future-proof than to install an RabbitMQ from 2015 ...
I have googled extensively on this issue but all I found was some bug about doubled headers in the rabbitmq client software that is not in use here. I traced it into apache httpclient classes and there is nothing on the sender side that smells.
Any suggestions what is wrong?
It turned out that the Apache HttpClient was adding a second content-type header to the message, caused the rejection on RabbitMQ Management plugin.
Yes, content type should not be applied
curl -s -i -u guest:guest -H "content-type: application/json" -H "content-type: application/json" -X POST --data '{"properties":{"delivery_mode":2},"routing_key":"program.*","payload":"{\"id\":\"123456\"}","payload_encoding":"string"}' 'http://127.0.0.1:15672/api/exchanges/%2F/my-exchange/publish'
return HTTP/1.1 415 Unsupported Media Type
Without content-type or just one :
curl -s -i -u guest:guest -H "content-type: application/json" -X POST --data '{"properties":{"delivery_mode":2},"routing_key":"program.*","payload":"{\"id\":\"123456\"}","payload_encoding":"string"}' 'http://127.0.0.1:15672/api/exchanges/%2F/my-exchange/publish'
return HTTP/1.1 200 OK
Related
I am trying to send a file using the POST request, with curl:
curl -v -u admin:admin -X POST -H 'Content-Type: application/xml' --data-binary '#test.xml' 'http://localhost:10215/'
I am getting the following errors:
Note: Unnecessary use of -X or --request, POST is already inferred.
* Could not resolve host: application
* Closing connection 0
curl: (6) Could not resolve host: application
Note: Unnecessary use of -X or --request, POST is already inferred.
* Could not resolve host: 'http
* Closing connection 1
curl: (6) Could not resolve host: 'http
Over Postman, I managed to send the file, by adding the file content in the body of the request. But how could I update the curl command, so that I could be able to send the file from the folder I am running the command from? The authentication is basic authentication and the Content-Type of the request must be specified.
If you have achieve it with postman, just copy the curl code that is generated by postman clicking in the code button:
I am able to login my local (and remote server) with the following curl (which I generated using Postman)... and I can login successfully using another API Client (Rested) with the same params/headers/body that I am trying to use in Postman. I've turned off "SSL cert verification" and "Send Postman Token header" in settings (per other Stack Overflow answers).. but still getting an unauthorized response from server when using Postman (but not when using curl or Rested)
curl:
curl -X POST \ http://localhost:8080/api/user/login \ -H 'Accept:
application/json' \ -H 'Content-Type: application/json' \ -d '{
"email": "email#example.com",
"password": "examplemail**" }'
And here is my log..
I just solved my own Q.. and posting this answer because I've seen other questions re: curl working but postman not on SO and Postman communities. My solution was to check the Content-Length header and Connection headers. They were auto populating anyway, so after 'accepting' them as headers, the Postman request worked. Here is a screenshot of the headers that worked.
We are setting up a reporting feed to a client and, in testing out the endpoint, we are receiving different responses between cURL (command-line) and Postman. In Postman, the request goes through, just fine; we get a 200-OK back. However, when we send the request in cURL, we get the following response back curl: (60) SSL certificate problem: certificate has expired
With cURL
The cURL request looks like the following:
curl -i -H "content-type: application/json" -d '{"foo": [],"bar": [],"baz": []}' https://test.example.com/notARealEndpoint
With Postman
The Postman setup is hard to display, but it's code-conversion looks like:
cURL interpretation
curl --location --request POST 'https://test.example.com/not/aReal/Endpoint' --header 'Content-Type: application/json' --header 'Content-Type: text/plain' --data-raw '{"foo": [],"bar": [],"baz": []}'
*This, by the way, returns the same certificate has expired error when run in command line
HTTP interpretation
POST /not/aReal/Endpoint HTTP/1.1
Host: test.example.com
Content-Type: application/json
Content-Type: text/plain
{"foo": [],"bar": [],"baz": []}
Looks like the target server has an expired SSL certificate. The reason that postman is not raising an error couble be because of disabled SSL verification checks.
You can disable those checks in curl by using a --insecure or -k option.
eg:
curl https://expired.badssl.com
Will throw the same error that you are seeing.
versus
curl --insecure https://expired.badssl.com
will return an html response body.
Following up on my earlier question, I realized that even if I SSH into my OpenShift container and attempt to manually cURL an HTTPS URL, it seems to get internally re-routed to the HTTP equivalent. How can I actually access the HTTPS version?
From my local machine:
$ curl -X POST -H “Authorization: Basic <TOKEN>” -H “Content-Type: application/x-www-form-urlencoded” -H “Content-Length: 0” https://api.stubhub.com/login
{”error”:”invalid_request”,”error_description”:”Missing grant_type parameter value”}
And from my remote machine (via SSH):
> curl -X POST -H “Authorization: Basic <TOKEN>” -H “Content-Type: application/x-www-form-urlencoded” -H “Content-Length: 0” https://api.stubhub.com/login
<HTML><HEAD>
<TITLE>Access Denied</TITLE>
</HEAD><BODY>
<H1>Access Denied</H1>
You don't have permission to access “http://api.stubhub.com/login” on this server.<P>
Reference #18.63de6bd1.1459386064.30c676b
</BODY>
</HTML>
Note the http URL in the latter's response body.
(And of course, I'm using a working/tested <TOKEN>.)
You should contact stubhub and see if they are blocking the ip address(es) that you are attempting the connection from. I am able to curl other https url's from OpenShift Online without any issues.
I am new to openstack, trying to use Ceilometer python API to pull some data from a testbed server, I am accessing the server from a remote site
the problem is that I cannot figure out how get the an authorization token
I used the following command
curl -i 'http://HOST:8774/' -X POST -H "Content-Type: application/json" -H "Accept: application/json" -d/tokens auth": {"tenantName": "project", "passwordCredentials": {"username": "user", "password": "password"}}}'
But it does not give me anything,
curl -X GET -H "X-Auth-Token:$MY_TOKEN" http://HOST:8774/tokens
also does not give me any token
From your use of port 8774 I suspect you might be using DevStack. Try this
curl -s -X POST http://$OPENSTACK_KEYSTONE_HOST:5000/v2.0/tokens -d '{"auth": {"passwordCredentials": {"username":"my-username", "password":"my-password"}, "tenantName":"my-tenantName"}}
In DevStack Keystone (the auth service you get tokens from) is running on port 5000 by default. This may or may not be true in your case. Ask your friendly OpenStack operator what host (and port) Keystone is running on and put that in place of $OPENSTACK_KEYSTONE_HOST:5000