What's the difference between "Request Payload" vs "Form Data" as seen in Chrome dev tools Network tab - forms

I have an old web application I have to support (which I did not write).
When I fill out a form and submit then check the "Network" tab in Chrome I see "Request Payload" where I would normally see "Form Data". What is the difference between the two and when would one be sent instead of the other?
Googled this, but didn't really find any info explaining this (just people trying to get javascript apps to send "Form Data" instead of "Request Payload".

The Request Payload - or to be more precise: payload body of a HTTP Request
is the data normally send by a POST or PUT Request.
It's the part after the headers and the CRLF of a HTTP Request.
A request with Content-Type: application/json may look like this:
POST /some-path HTTP/1.1
Content-Type: application/json
{ "foo" : "bar", "name" : "John" }
If you submit this per AJAX the browser simply shows you what it is submitting as payload body. That’s all it can do because it has no idea where the data is coming from.
If you submit a HTML-Form with method="POST" and Content-Type: application/x-www-form-urlencoded or Content-Type: multipart/form-data your request may look like this:
POST /some-path HTTP/1.1
Content-Type: application/x-www-form-urlencoded
foo=bar&name=John
In this case the form-data is the request payload. Here the Browser knows more: it knows that bar is the value of the input-field foo of the submitted form. And that’s what it is showing to you.
So, they differ in the Content-Type but not in the way data is submitted. In both cases the data is in the message-body. And Chrome distinguishes how the data is presented to you in the Developer Tools.

In Chrome, request with 'Content-Type:application/json' shows as Request PayedLoad and sends data as json object.
But request with 'Content-Type:application/x-www-form-urlencoded' shows Form Data and sends data as Key:Value Pair, so if you have array of object in one key it flats that key's value:
{ Id: 1,
name:'john',
phones:[{title:'home',number:111111,...},
{title:'office',number:22222,...}]
}
sends
{ Id: 1,
name:'john',
phones:[object object]
phones:[object object]
}

tl;dr of lefloh's (excellent) answer:
If an HTTP request has a message body, it is a "Request Payload"
"Form Data" is a subset of Request Payload in which the body is encoded as key1=value1&key2=value2
Whenever Google Chrome can distinguish Form Data from a generic Request Payload, it customizes the formatting

Related

What exactly is sent when a RESTful request is sent. How is the information in the METHOD and BODY sent to the URL?

trying to understand more about RestFul calls. I understand the format, but what I want to know is how the call is actually sent. For example, if I were to setup Fiddler on my client, and I were to make a RestFul call to http:/thisplace.com/rws with Method = POST and Body = Login HTTP/1.1
Host: client.mydomain.com
Accept: application/xml
Content-type: application/xml
What exactly do I see being sent out from the client on fiddler? Is the information coded inside the URL?
Wondering if RestFul calls can be sent without a third-party tool such as PostMan.
RestFul services use standard HTTP methods (GET, POST, PUT, DELETE, etc). The parameters in a HTTP POST request are sent in the request body which appears after the headers. The information/parameters are not encoded in the URL in a POST request.
The format that the parameters are sent depends on the Content-Type of the request.
In your example you specify content-type: application/xml which means you'd need to provide xml in the request body. In fiddler an HTTP POST to http://thisplace.com/rws might look something like this (for application/xml):
POST http://thisplace.com/rws HTTP/1.1
Content-Type: application/xml
Accept: application/xml
Host: thisplace.com
content-length: 64
<myData>
<value>hello</value>
<value2>world</value2>
</myData>
The request body is below the headers and is the after the blank line where you see the xml.
If you specified application/json the parameters would be encoded as json, and the request body might look like:
{
"value1": "hello",
"value2": "world"
}
For content type application/x-www-form-urlencoded the parameters would be in the same format as a query string and the request body might look like:
value1=hello&value2=world
Yes, RestFul calls can be made without postman but you haven't specified which language/technology you're using or how you'd like to send the requests.

Postman API Invalid Content-Type Header

I'm trying to test and API call for the Smartsheet API in Postman, but I keep receiving the same error. Even though I am defining the correct Content-Type as per the API documentation, the response I get is the error 1124, which is an invalid content-type header. I haven't been able to figure out exactly what is causing the issue. I have tried typing the header in the address and in the header tab in Postman, but neither option has given me the result I wanted.
Postman Screenshot
If I run the same request in Postman as your screenshot shows (except using my sheet ID), with the same headers that you're using, my request succeeds. i.e., if you're sending the Content-Type header with value application/json for this request, you should not be receiving the error message that you're reporting (1124 - invalid content-type header).
You would, however, receive that error message if you were either not including the Content-Type header at all OR if you were specifying an invalid value for the Content-Type header. A suggestion for troubleshooting: use Fiddler (or a similar tool) to examine the request that's being sent over the wire when you execute this request in Postman -- does it include the Content-Type header, and if so, what's the value of that header?
UPDATE:
Thanks for adding a screenshot of the body you're setting in Postman -- I believe that's the source of your issue. i.e., your Content-Type header says that the request body is in JSON format, but you're actually not sending JSON. To fix this: instead of specifying key/value pairs in Postman, select the raw radio button and specify the body in JSON format. Here's a screenshot of what that looks like:

Why do we prefer Authorization Header to send bearer token to server over other techniques like URL encoding

Why Authorization header is mostly used to send a bearer token to server? Why don't we send our authorization token as URL parameter or post it as json payload with the request body?
Headers are perfect to hold these data, they are independent of request type.
You could send Authorization token in body, even everything other like Content-Type, Content-Length, cache headers also but different request types (POST,GET..) could have different request body format. GET sends data using query parameters POST/PUT in encoded form in the body (with Content-Type: application/x-www-form-urlencoded to make server aware of incomming data format), Content-Type: application/json with JSON in body, XML and others. Things get more complicated on multipart requests (check this https://stackoverflow.com/a/19712083/1017363).
So as you can see authorization token in body or query makes things more complicated on client and server side. Client should know how to "fit" authorization token on every request and server should know then how to read this value.

How send application/x-www-form-urlencoded params to a RestServer with JMeter?

I developed a rest server, and I put it to run in localhost, and I'm trying to perform tests with JMeter, sending requests posts and gets (depends of called method).
I already send to Rest server and got result with JMeter in simple post requests, get requests, sending files with post, and sending a Json with post.
But I don't know how to send a Form-UrlEncoded object to server. My Rest server consumes application/x-www-form-urlencoded, and I need to send 3 String parameters.
There's some way to set the MimeType for every parameter and perform the test ?
I'm using Jmeter 2.7
[Update]
I solved this by disabling the option:
use multipart/form-data for post
And enabling:
redirect automatically
Instead of:
follow redirect
The parameters I put normally in the table "Send parameters with the Request" with each respective names.
For sending form parameters as application/x-www-form-urlencoded, add a header parameter Content-Type with value application/x-www-form-urlencoded.
The following steps is aplicable for Jmeter 2.3.4
Add a HTTP Header Manager under your http Request.
Add new parameter to HTTP Header Manager with name Content-Type and value application/x-www-form-urlencoded.
Uncheck "Use multipart/form-data for HTTP POST" of HTTP request.
Uncheck "Encode?" of each request parameter(not necessary).
kept "Content Encode:" text box of HTTP request as empty.
This won't work for PUT request.
For put request add parameters as path parameter and set Content-Type header then Jmeter will do by itself.
Here's the solution for HTTP POST with x-www-form-urlencoded testing with jmeter. You just folllow like these.
Go to Thread Group -> Add listener -> Views Result in table, View result Tree. To see the process of responding.
Have you tried to save your test using BadBoy or JMeter Proxy to see what your application actually sends?
To see what happens under the hood you can also use FireBug if you're using FireFox or Ctrl+Shift+i if you're on Chrome.
IllegalCharsetNameException will go immediately only after you will add the required content-type in HTTP Header Manager for HTTP request .
Hope this helps.
followed exact steps mentioned i still see an exception thrown
Response code: Non HTTP response code: java.nio.charset.IllegalCharsetNameException
Response message: Non HTTP response message: application/x-www-form-urlencoded
java.nio.charset.IllegalCharsetNameException: application/x-www-form-urlencoded
at java.nio.charset.Charset.checkName(Charset.java:315)
at java.nio.charset.Charset.lookup2(Charset.java:484)
at java.nio.charset.Charset.lookup(Charset.java:464)
at java.nio.charset.Charset.forName(Charset.java:528)
at org.apache.http.entity.ContentType.create(ContentType.java:210)
at org.apache.http.entity.StringEntity.<init>(StringEntity.java:116)
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sendPostData(HTTPHC4Impl.java:1340)
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.handleMethod(HTTPHC4Impl.java:592)
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:409)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1166)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1155)
at org.apache.jmeter.threads.JMeterThread.executeSamplePackage(JMeterThread.java:475)
at org.apache.jmeter.threads.JMeterThread.processSampler(JMeterThread.java:418)
at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:249)
at java.lang.Thread.run(Thread.java:745)

Accessing request payload from RESTful calls in Tornado Web

I have a basic app set up using Backbone.js and Tornado Web. When I save my Backbone model, it fires off a POST request to one of my handlers' post methods. I want to access the variables inside the payload but the arguments dictionary is empty.
Request Payload
{"text":"dghjdg","date":"2012-02-05T11:23:46.105Z","author":"Kevin"}
Response Headersview parsed
HTTP/1.1 200 OK
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Server: TornadoServer/2.2
It seems as if self.get_argument in the handler only collects data from Form Data in the request header and not the Request Payload part. How can I access any of the variables in the Request Payload?
Request body (or payload) can be accessed using self.request.body. Obviously you must decode the JSON format, e.g. json.loads(self.request.body).