Content-Type in the HTTP Header

1. HTTP Header

The HTTP protocol is an application-layer specification built on top of TCP/IP, transmitted as ASCII text. The HTTP specification divides an HTTP request into three parts: the status line, the request headers, and the message body. Something like this:

1
2
3
4
5
<method><request-URL><version>

<headers>

<entity-body>

An HTTP header falls into four categories: general headers, request headers, response headers, and entity headers. Each header field consists of a field name, a colon, and a field value.

General headers are usable by both client and server. They provide useful common functionality shared between clients, servers, and other applications, such as the Date header.
Request headers are specific to request messages. They give the server extra information, such as what type of data the client wants to receive — for example the Accept header.
Response headers provide information to the client, such as what kind of server the client is interacting with — for example the Server header.
Entity headers are the headers that describe the entity body. For instance, an entity header can state the data type of the entity body, such as the Content-Type header.

2. File Requests and API Requests

Client-server interaction usually falls into two categories: requesting files (html, js, css, and so on), and requesting API data.

But in the course of an HTTP request, the two are handled the same way.

Most browsers limit URL length to within 2K bytes, while most servers process URLs of at most 64K. If you use GET with data carried in the body, different servers handle it differently: some may process it, others simply ignore it.

The HTTP specification requires that data submitted by POST be placed in the message body (entity-body), but the protocol does not dictate what encoding the data must use. Servers typically read the Content-Type field of the entity headers in the HTTP header to determine which encoding the request uses, and then parse the message body.

3. Several Content Types

The Content-Type attribute specifies the HTTP content type of a request or a response.

Common Content-Types:

text/html, HTML file type
text/plain, plain text type
text/css, CSS file type
text/javascript, JavaScript file type
application/x-www-form-urlencoded
multipart/form-data
application/json
application/xml

3.1 application/x-www-form-urlencoded

Data submitted by POST is encoded as key1=val1&key2=val2, with both key and val URL-encoded. Most server-side languages support this well, and a browser’s native form submits exactly this way.

1
2
3
Content-Type: application/x-www-form-urlencoded;charset=utf-8

title=test&sub%5B%5D=1&sub%5B%5D=2&sub%5B%5D=3

3.2 multipart/form-data

Data submitted by POST is organized into Key-Value form and split into individual messages by the boundary separator. It can be used both to upload files and to upload parameters. When a form’s form is set to multipart/form-data, it submits this way.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryrGKCBY7qhFd3TrwA

------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="text"

title
------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="file"; filename="chrome.png"
Content-Type: image/png

PNG ... content of chrome.png ...
------WebKitFormBoundaryrGKCBY7qhFd3TrwA--

3.3 raw

Data is encoded as plain text (text/json/xml/html), containing no control or formatting characters. The more common Content-Type values are application/json, text/xml, text/plain, and so on.

1
2
3
Content-Type: application/json;charset=utf-8

{"title":"test","sub":[1,2,3]}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
Content-Type: text/xml

<?xml version="1.0"?>
<methodCall>
    <methodName>examples.getStateName</methodName>
    <params>
        <param>
            <value><i4>41</i4></value>
        </param>
    </params>
</methodCall>

4. Postman

As a cross-platform API testing tool, Postman offers Win/Mac/Linux clients as well as a Chrome extension. Frontend developers, backend developers, and testers alike can use Postman to test APIs, and it is very convenient to work with. Postman lets users send any type of HTTP request — GET, POST, HEAD, PUT, DELETE, and so on — with arbitrary parameters and Headers. It also supports different authentication mechanisms, including Basic Auth, Digest Auth, OAuth 1.0, OAuth 2.0, Hawk Authentication, and AWS Signature, and it can automatically format and highlight response data.

In addition, Postman provides the following features.

Debugging and logs: debug Postman requests in the console — especially useful when you have a pre-request or test script. In native Postman, open the console with CMD/CTRL + ALT + C.
Generate code snippets: export the current request as request code in various languages, such as Python, js, curl, and so on, which makes command-line testing convenient.
Proxy: if your machine cannot reach the server directly, set a proxy under Settings-Proxy-Using custom/system proxy.
Capturing HTTP requests: sometimes when accessing the server from a phone we may need fiddler to inspect HTTP requests. Postman can do the same job — just use Postman as a proxy to forward HTTP requests.
Certificates: if the server verifies client certificates, configure the certificate under Settings-Certificates-Add Certificate.
pre-request script: a script that runs before the request is sent, generally used to build the request parameters;
test script: a script that runs after the response is received, generally used for testing. Note, however, that test scripts run in a Sandbox environment with many built-in JS libraries available, which makes testing convenient.
Sharing collections: export requests from a Collection and share them with others;
Data formats: Postman can export environment variables, and can even package requests and environment variables together into a single Json, making it easy to migrate all the request data
Using environments in collection runs: specify an Environment so that requests in the collection can use its variables;
Working with data files: import a Data File holding the Data variables used in testing. You can store many different Data variables, so that when the Collection runs multiple iterations each one uses different data;
Running multiple iterations: configure iterative runs of the requests in a Collection to test API stability. Combined with Data files, it can also test API correctness;
Building workflows: by default the requests in a Collection execute in order, but setNextRequest() can change the execution flow of the requests.
Debugging a collection run: after the requests in a Collection run, a visual display of the results makes debugging convenient; you can also debug through the console.
Sharing a collection run: an entire Collection Run can also be exported and run on other platforms;
Command line integration with Newman after exporting a Collection Run, you can run it from the command line with newman.
Integration with Travis CI: newman can be integrated with Travis CI, set up for continuous integration, and configured with the timing for automatically running test cases.