Every time I send a pretty minimal request to Parse API:
POST /1/some_url HTTP/1.1
X-Parse-Application-Id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
X-Parse-REST-API-Key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Content-Type: application/json
{"data":"value"}
I get the same empty response:
HTTP/1.1 400 BAD_REQUEST
Content-Length: 0
Connection: Close
And ideas about possible errors on my part?
Answering my own question. In my case an additional header was needed:
Host: api.parse.com
Related
From my laptop I initiated a POST request to my web server. The HTTP POST request looks something like this (when seen via POSTMAN console)
POST /api/fwupgrade HTTP/1.1
User-Agent: PostmanRuntime/7.24.1
Accept: */*
Cache-Control: no-cache
Postman-Token: 2b1e72fa-f43b-4fc9-9058-e78533c30f0f
Host: 192.168.71.24
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Type: multipart/form-data; boundary=--------------------------572971355726244237076370
Content-Length: 222
----------------------------572971355726244237076370
Content-Disposition: form-data; name="FileName"; filename="help.txt"
<help.txt>
The content-length is indicated as 222. the file help.txt has the following characters only (for test I put 10 a)
aaaaaaaaaa
When I receive a http request on the server, I parse the request and I see the content-length as 222. Now my questions:
a) I assume this content length 222 includes the bytes after the line "Content-Length: 222" am I right? So this would mean the request body starts from
------------------572971355726244237076370
Content-Disposition: form-data; name="FileName"; filename="help.txt"
<help.txt>
Is this understanding correct?
b) Does the request body always follow the same format i.e after "Content-Length:" it begins and ends with the data of the file, in my case "help.txt"?
c) Assuming #a is correct, I calculate the actual data to be starting from the location after filename="help.txt" /r/n and then store this in a file on my server. However I get 58 surplus bytes after the aaaaaaaaaa. Any idea how am I supposed to interpret Content-length or how postman calculates the Content-length field?
Regards
a) Roughly yes.
b) It depends on the Content-Type (here: multipart/form-data)
c) You'll need a parser for multipart/form-data messages. See, for instance, https://greenbytes.de/tech/webdav/rfc7578.html
I am quite new to Fiddler and it looks like an awesome tool to me.
What i wanted to do is generate a sequence of POST requests.
Explaination:
POST https://www.website.com/user/login HTTP/1.1
Host: www.website.com
Connection: keep-alive
Content-Length: 552
Cache-Control: max-age=0
Origin: https://www.website.com
Upgrade-Insecure-Requests: 1
DNT: 1
Content-Type: application/x-www-form-urlencoded
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8
Referer: https://www.website.com/user/login
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Cookie: ASP.NET_SessionId=mpdxdkrjujkzchwblg1ys2y3; ai_user=u0IpN|2018-09-25T16:12:07.607Z; ai_session=+Ip5T|1537899054881.5|1537899121420.5
__VIEWSTATE=something here PageContent%24txtRoll=14600&ctl00%24PageContent%24txtDOB=01%2F01%2F2001&ctl00%24PageContent%24btn_submit=LOGIN
i want to make a loop of request such that the DOB field takes value like
01%2F01%2F2001
then, 01%2F02%2F2001
then, 01%2F03%2F2001
and so on.. keeping everything else same.
And if the response from server is Code:302 then stop the loop or otherwise if the value reaches 31 then too stop the loop.
Thanks in advance.
Any suggestions are welcome.
P.S. :Sorry for the messy question, i don't know how could i say it in simple words.
You need to write a script which will do that for you. Here's an article that might help you.
https://www.telerik.com/blogs/understanding-fiddlerscript
Personally I'd write a script that does the task in python or any other language you know using any http library
I am trying to get an access token from the Pay Pal REST API, following this article: https://developer.paypal.com/docs/api/overview/#get-an-access-token
My request looks like this:
POST https://api.paypal.com/v1/oauth2/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Accept: application/json
Accept-Language: en_US
Authorization: Basic [redacted]
Host: paypal.com
Content-Length: 31
Expect: 100-continue
Connection: Keep-Alive
grant_type=client_credentials
But I keep getting 400 Bad Request with the following response data:
{ “error”: “unsupported_grant_type”, “error_description”: “unsupported grant_type” }
I can't figure out why - as far as I can see, I've followed the instructions exactly!
Their "Merchant Techincal Support" has been absolutely no help.
TLDR; PayPal REST API's GetAccessToken endpoint does not trim whitespace.
I solved it. The astute will notice the following discrepancy:
Content-Length: 31
...
grant_type=client_credentials
The data is only 29 characters - the extra two being \r\n carriage return and line feed.
In code (I'm using C#/.NET) this was a matter of changing:
writer.WriteLine("grant_type=client_credentials");
To
writer.Write("grant_type=client_credentials");
This corrected the issue.
If you're using Postman, add it to Params tab. Like so:
I am getting 400 Bad request - Your browser sent an invalid request. for the request. The request size is 28KB.
< HTTP/1.0 400 Bad request
< Cache-Control: no-cache
< Connection: close
< Content-Type: text/html
<
<html><body><h1>400 Bad request</h1>
Your browser sent an invalid request.
</body></html>
I have following configurations in my haproxy.conf
maxconn 100000
tune.bufsize 32768
tune.maxrewrite 1024
What is the right settings to solve 400 Bad request error.
based on this link: https://www.geekersdigest.com/max-http-request-header-size-server-comparison/
looks like the request header is too big. It should be smaller than 16K, which is the default header size limit
I'm trying to find out the problem in a communication issue between my klient and a REST API.
I can identify the problem but I'm not sure what is exactly missing in the answer for the OPTION request.
My application is creating a HTTP POST what is preflighted by the browser with a HTTP-OPTION. The option is asking for approving the custom Content-type. After the server answers the OPTION the POST is not sent.
OPTIONS /element_collection/VizRundown/channels/ExampleChannel/playlists/continuous/ HTTP/1.1
Host: localhost:8580
User-Agent: Mozilla/5.0.........
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type
Accept: */*
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US......
Origin: null
Here is how the answer looks like:
200 OK
Access-Control-Allow-Origin: *
Allow: GET, POST, OPTIONS
Content-Type: text/plain
Server: MediaSequencer/1.23.1.11957 soul/014dfd135460
Transfer-Encoding: chunked
Am I correct that there should be a line int the answer approving the requested Content-Type? Like this:
Access-Control-Allow-Headers: content-type
No, it is not required as per the relevant sections of the spec.
http://www.w3.org/TR/cors/#resource-preflight-requests:
In response to a preflight request the resource indicates which
methods and headers (other than simple methods and simple headers) it
is willing to handle and whether it supports credentials.
http://www.w3.org/TR/cors/#terminology:
A header is said to be a simple header if the header field name is an
ASCII case-insensitive match for Accept, Accept-Language, or
Content-Language or if it is an ASCII case-insensitive match for
Content-Type and the header field value media type (excluding
parameters) is an ASCII case-insensitive match for
application/x-www-form-urlencoded, multipart/form-data, or text/plain.