Postman - Error 400 Bad Request - json

I'm trying to access an API using Postman to get a response using basic authentication, but when I submit the data, it gives me the dreaded 400 error, which apparently indicates that some headers aren't set up properly.
Here's the API info:
Request
Endpoint: {loginUrl}
Data to submit: an email and a password
POST /login HTTP/1.1
Host: {baseUrl}
Accept: application/json
Content-Type: application/json
Content-Length: 68
{
"email": "{email}",
"password": "{password}"
}
And in response, I should get an encrypted token in form of JSON, instead I'm getting this error.
Here are the postman screenshots:
Am I missing something?

I also faced the same issue and i updated my postman header with the below image. And issue solved.

From the lack of details it's difficult to offer a specific answer but I can offer something that you can try - The Request data you posted in the question looks like you should be adding:
{
"email": "{email}",
"password": "{password}"
}
In the Body section of the request but your images don't show that you've added that to the Body on any request, you've added it as a Auth header instead, so remove that before trying again. I'm not sure of the need to add the Content-Length header as that will change for different username and password combinations in the payload or for the length of the response.

In case anyone finds this helpful, I ran into the same issue and the culprit turned out to be missing headers. I knew I needed the "Content-Type": "application/json" header, which I already had in place, but I didn't know that I was missing two other headers.
The solution for me was also adding the "Content-Length" and "Host" headers in Postman.
I see some others have questioned the need for the "Content-Length" header, but in my case, the minimum three needed were "Content-Type", "Content-Length", and "Host" or it would always fail.

I faced a similar issue. it got resolved when i called my placeholder as a tuple.

Related

Invalid request, post must use JSON when using Postman

I'm trying to log into a website and using Postman to work out the POST.
The url is https://vaxmgmt.force.com/authorizedEnroller/s/login/?ec=302&startURL=%2FauthorizedEnroller%2Fs%2F
The html for the username and password are:
And the submit button:
I have in the headers "Content-Type" "application/json"
In the body/raw I have {"username":"username","password":"password"}
with a valid username and password
The headers that come back are:
Then I get "Invalid request, post must use JSON"
I'm just not sure where to go from here.
Did you select JSON as body type? It's on the right from radiobuttons with "none", "form-data", "raw"... and then a dropdown that has JSON as an option.
like here
p.s. Also, you said you used "Content-Type" "application/jason" - are you sure you didn't make a typo in json here? Please double check that just in case :)

Unable to hardcode JSON response

I'm currently working with Angular 5.1.2 and i'm trying to get objects from http requests.
In order to verify my code, I've hardcoded a JSON response and created a Python Anywhere's web service, here's what I did :
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/json; charset=UTF-8
{"Computer":[{
"ip":"192.168.0.142",
"mac":"39-D7-98-9E-5A-DC",
"name":"PC-DE-JEAN-CLAUDE"
},
{
"ip":"192.168.0.50",
"mac":"4D-49-98-30-8A-F5",
"name":"LIVEBOX-684J"
}]}
However, why my Angular app is saying that "No 'Access-Control-Allow-Origin' header is present on the requested resource" ?
Thanks
It is related to CORS issue. It happens when server and client are running on different addresses. To make it run, server need to return Access-Control-Allow-Origin as a Key:Value pair in their header response.
Access-Control-Allow-Origin: *
Specifying value as * means that the content of the address can be accessed by any other address.
It's one of the layer in securing the Internet applications.
This is a server-side problem due to CORS to prevent XSS. In order to fix, make sure your server responds with the header Access-Control-Allow-Origin: * After verifying this fixes the problem, set this header to your website URL

Jmeter does not send JSON data in POST

I am trying to do a POST in jmeter with a json as the body data but I just get a 400 back. The URL I am sending to only accepts json. I have used the same curl in Postman and it worked just fine. I have tried putting the json in the parameters as a value with no name and that didnt work.
I am just trying to send {"uid":"jmtest","name":"newdevice"}.
Sorry I cant post more links.
The sampler result is
Thread Name: QA test 1-1
Sample Start: 2016-05-11 11:50:19 MDT
Load time: 86
Connect Time: 51
Latency: 86
Size in bytes: 282
Headers size in bytes: 244
Body size in bytes: 38
Sample Count: 1
Error Count: 1
Data type ("text"|"bin"|""): text
Response code: 400
Response message: Bad Request
Response headers:
HTTP/1.1 400 Bad Request
Server: nginx
Date: Wed, 11 May 2016 17:50:19 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 38
Connection: keep-alive
X-Request-Id: 88339ee9-b74f-4e22-b581-e3124949d067
X-Runtime: 0.030877
HTTPSampleResult fields:
ContentType: application/json; charset=utf-8
DataEncoding: utf-8
And the request looks like
/url redacted
POST data:
{"devices":{"uid":"jmtest","name":"newdevice"}
[no cookies]
Request Headers:
Connection: keep-alive
Accept: application/vnd.moneydesktop.v2+json
Content_Type: application/json
MD-SESSION-TOKEN: redacted
Content-Type: application/x-www-form-urlencoded
Content-Length: 46
Host: redacted
User-Agent: Apache-HttpClient/4.5.2 (Java/1.8.0_72)
The response data is
{
: "status":"400",
: "error":"Bad Request"
}
To send a POST HTTP Request with the JSON Data inside the body, need to add,
HTTP Header Manger into your request and set the name as 'content-type' and value as 'application/json' this will attached into HTTP request header and what ever the data inside your request body will send as json format.
Image 1:Set HTTP Header Manager,
Image 2:Set HTTP Request Body Data
Make sure your HTTP Header Manager is configured to send Content-Type header with the value of application/json
Given you have samplers like "home page" and "login" it might be the case you're missing HTTP Cookie Manager
The most straightforward way to see what's wrong is to capture requests sent by Postman (whatever it is) and JMeter by a sniffer tool like Wireshark, identify the differences and configure JMeter accordingly.
Finally, it looks like you're using some developer snapshot so approach to pass JSON payload as 1st argument without name might not work. Try switching to "Body Data" instead.
If above steps won't help update your question with screenshots of View Results Tree listener (all 3 tabs) and Postman
Check out Testing SOAP/REST Web Services Using JMeter for more tips.
This solution from Dmitri T, really worked for me.
Make sure your HTTP Header Manager is configured to send "Content-Type" header with the value of "application/json".
I have faced the same issue and it was resolved by setting the value of Content Encoding to utf-8 in http request. Please try.
First thing you might wanna do is put the payload inside "Body Data" Instead of "Parameters"
Then, add a config element "HTTP Header Manager"
And add a parameter "content-type" With corresponding value "application/json"
Now hit. Should do!
I figured out my problem. I had set Content_type instead of Content-Type so it was creating two content type headers.
Though Hasiya explain really well but missed how to find http request.
If you chose http default will not see method option .
I had given HTTP/1.1 415 Unsupported Media Type
After deleting space before of HTTP Header Manager ,It got 200 and worked like a charm
You must use body data, not parameters. cut and paste it the next tab on your request. Also you should change implementation to Java and check if your token is valid. Finally check your results from view results tree reporting item. It must be work for you.
In addition to many said above, make sure that the copy/paste of Accept, Content-Type from website doesn't have a trailing space! It costs me many hours to figure it out. Just a caution.
Just edit to add that if that mistake happens, return code is 415: Unsupported Media Type
Insert your json in body data field.
In your HTTP Header Manager set the headers stores to:
"name" : Content-Type
"value": application/json
Yes, we need to pass the Content-Type header.
I faced the same issue and it took nearly a day to figure out until I came across this link - https://www.blazemeter.com/blog/performance-test-web-services
Header:
Name: Content-Type Value: application/json;charset=utf-8
If none of the abovementioned solutions work for you (as it was for me) take a second look at the HTTP Header Manager. I had empty header line there
Removing it solved the problem
I was facing the similar issue, the size of my request body was also huge so along with updating content-type as application/json, i gave content encoding as utf-8 and it worked perfectly fine.
As per your attached pic , You have pasted the request in queryparameters , the payload must be in body part
check the screenshot you have payload in queryParam section
Setting the HTTP header manager fixed the issue for me
HTTP Header Manager:
Name: Content-type and Value: application/json has resolved issue.

Using file as payload in Advanced REST Client

I'm trying to work with the Advanced REST Client of Google.
I installed the extension, and I can work with it.
Now I wanted to use a JSON-file as input for my payload.
The JSON-file looks as follows :
{"UserName":"", "UserPassword":"","SetDebug":true}
The Content-Type is set to application/json.
But when I try to send the request I get the following error:
{
"Message": "The request entity's media type 'multipart/form-data' is not supported for this resource."
}
What am I doing wrong? Can anyone help me?
The ARC seems to override your Content-Type selection sometimes, changing it to multipart-form-data. If you select Files for the body and pick a file, it shows a message saying:
The Content-Type header will finally be changed to "multipart/form-data" during the request.
When you submit the request, it does exactly that: changes the Content-Type header. You can confirm this by looking in the Request Headers part of the output display.
I don't know if there's any way to stop it doing this :(-

What is "406-Not Acceptable Response" in HTTP?

In my Ruby on Rails application I tried to upload an image through the POSTMAN REST client in Base64 format. When I POST the image I am getting a 406 Not Acceptable Response. When I checked my database, the image was there and was successfully saved.
What is the reason for this error, is there anything I need to specify in my header?
My request:
URL --- http://localhost:3000/exercises.json
Header:
Content-Type - application/json
Raw data:
{
"exercise": {
"subbodypart_ids": [
"1",
"2"
],
"name": "Exercise14"
},
"image_file_name": "Pressurebar Above.jpg",
"image":"******base64 Format*******"
}
Your operation did not fail.
Your backend service is saying that the response type it is returning is not provided in the Accept HTTP header in your Client request.
Ref: http://en.wikipedia.org/wiki/List_of_HTTP_header_fields
Find out the response (content type) returned by Service.
Provide this (content type) in your request Accept header.
http://en.wikipedia.org/wiki/HTTP_status_code -> 406
406 Not Acceptable
The resource identified by the request is only capable of generating response entities which have content characteristics not
acceptable according to the accept headers sent in the request.
406 happens when the server cannot respond with the accept-header specified in the request.
In your case it seems application/json for the response may not be acceptable to the server.
You mentioned you're using Ruby on Rails as a backend. You didn't post the code for the relevant method, but my guess is that it looks something like this:
def create
post = Post.create params[:post]
respond_to do |format|
format.json { render :json => post }
end
end
Change it to:
def create
post = Post.create params[:post])
render :json => post
end
And it will solve your problem. It worked for me :)
"Sometimes" this can mean that the server had an internal error, and wanted to respond with an error message (ex: 500 with JSON payload) but since the request headers didn't say it accepted JSON, it returns a 406 instead. Go figure. (in this case: spring boot webapp).
In which case, your operation did fail. But the failure message was obscured by another.
You can also receive a 406 response when invalid cookies are stored or referenced in the browser - for example, when running a Rails server in Dev mode locally.
If you happened to run two different projects on the same port, the browser might reference a cookie from a different localhost session.
This has happened to me...tripped me up for a minute. Looking in browser > Developer Mode > Network showed it.
const request = require('request');
const headers = {
'Accept': '*/*',
'User-Agent': 'request',
};
const options = {
url: "https://example.com/users/6",
headers: headers
};
request.get(options, (error, response, body) => {
console.log(response.body);
});
Changing header to Accept: */* resolved my issue and make sure you don't have any other Accept Header
In my case, I added:
Content-Type: application/x-www-form-urlencoded
solved my problem completely.
If you are using 'request.js' you might use the following:
var options = {
url: 'localhost',
method: 'GET',
headers:{
Accept: '*/*'
}
}
request(options, function (error, response, body) {
...
})
In my case for a API in .NET-Core, the api is set to work with XML (by default is set to response with JSON), so I add this annotation in my Controller :
[Produces("application/xml")]
public class MyController : ControllerBase {...}
Thank you for putting me on the path !
It could also be due to a firewall blocking the request. In my case the request payload contained string properties - "like %abc%" and ampersand symbol "&" - which caused the firewall to think it is a security risk (eg. a sql injection attack) and it blocked the request. Note here the request does not actually go to the server but is returned at the firewall level itself.
In my case, there were no application server logs generated so I knew that the request did not actually reach the server and was blocked before that. The logs that helped me were Web application firewall (WAF) logs.