A cookies header.
Headers define meta information about the request, like what is the content-type of the request body.
What are the acceptable response types etc.
Request BodyThe last and final part of a request is the body.
After the headers, there is a blank line which signifies that the headers are finished and the next data is the request body.
The request body is used to send arbitrary data to the server.
It could be JSON, simple text or even binary code.
The body is only enabled on certain HTTP methods.
GET requests don’t have a body.
POST, PUT and PATCH requests do.
The type of data in the body is defined by the Content-Type header.
If you're sending JSON data to the server then the content-type would be application/json.
Structure of HTTP ResponsesAs stated, HTTP requests and responses are just plain text files.
So the structure of an HTTP response is similar to a request with some differences.
They also consist of 3 parts.
A status lineZero or more headersA blank line denoting the beginning of the bodyAn optional message bodyBelow is an example of an HTTP response.
HTTP/1.
1 200 OKServer: nginx/1.
14.
0 (Ubuntu)Date: Sun, 19 May 2019 12:50:50 GMTContent-Type: text/htmlContent-Length: 612Last-Modified: Sun, 19 May 2019 12:49:34 GMTConnection: keep-aliveETag: "5ce150de-264"Accept-Ranges: bytes<!DOCTYPE html><html><head><title>Welcome to nginx!</title><style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; }</style></head><body><h1>Welcome to nginx!</h1><p>If you see this page, the nginx web server is successfully installed andworking.
Further configuration is required.
</p><p>For online documentation and support please refer to<a href="http://nginx.
org/">nginx.
org</a>.
<br/>Commercial support is available at<a href="http://nginx.
com/">nginx.
com</a>.
</p><p><em>Thank you for using nginx.
</em></p></body></html>Let’s break it down shall we?Status LineThe status line is the first thing in an HTTP responseHTTP/1.
1 200 OKIn order, it has 2 parts:The HTTP versionThe HTTP status code and its textual meaningIn the above example, HTTP/1.
1 is the version and 200 OK is the status code and text.
Response HeadersJust like with the request, HTTP responses contain headers which contain metadata about the response.
These are simply key-value pairs separated by a semi colon :.
We can see that the Content-Type header in the above example contains the value text/html denoting that is will contain HTML.
Response BodyThe response body is such that it contains the actual response content sent by the server.
Almost every HTTP response has a response body.
The content of the response can be virtually anything.
HTML, JSON, XML, you name it.
However, mostly the HTTP responses contain HTML or JSON.
In the above example, the response body starts after the first blank and the response body contains the actual HTML that will be sent to the browser.
HTTP Status CodesOne of the most popular and useful things about HTTP is its use of status codes.
Status code indicate the status of the requested resource or document.
The status code is simply the number in the status line of a response and is always in the hundreds range, e.
g.
200, 302, 404 etc.
Here are some of the most popular status codes.
You might’ve seem some of them on the web.
200 OK: Indicates a successful request and returns the response.
301 Moved Permanently: The resource has been moved to a new location.
Mostly used to redirect to the resource.
400 Bad Request: Used when there is an error in the HTTP request.
403 Forbidden: Indicates that the client does not have the necessary authorization to access the resource.
404 Not Found: The resource is not found.
418 I’m a teapot: Used when the server refuses to brew coffee because it’s a teapot.
(Yes, this is real).
500 Internal Server Error: Raised when the web server encounters and error that is not handled properly.
And the full list of codes can be found here.
SecurityNow, there is a lot to be said about security in HTTP.
HTTP does provide basic access authentication.
What that means is that the client would have to supply a username and a password to get access to the resource on the server.
But that is just a rudimentary mechanism and we need better security in modern apps.
HTTP was created in such a way that makes it easy to read by humans (i.
e.
uses plain text and formatting).
However, this introduces some complications.
By default HTTP does not encode or encrypt the message or headers in anyway.
So, if a request is sent to a server through a client, that request goes through a network of routers and switches and servers.
Any one of those servers can read the content or message of the request or response.
So if I send the username and password of my bank account through an HTTP post request, any router or server that comes between the bank’s server and my computer can read my credentials.
There are ways to overcome this which I will talk about below.
A Stateless protocol.
HTTP is designed as a stateless protocol.
What this means is that in a pure HTTP request/response cycle, the client and the server do not retain any information about each other.
It is not the responsibility of the HTTP protocol itself to recognize the authenticity of the client or the server.
While this decision has decreased the implementation complexity of the protocol, I believe it introduces chances of attacks such as phishing attacks and cross-site request forgery attacks.
So web developers have developed techniques to ensure such security.
In my opinions, such security measures should be built-in to the protocol.
Best PracticesHere I will list down what I think are best practices when using HTTP.
Whether it be spinning up a traditional template based app, creating an API or creating a microservices based architecture, here is what I think we should do.
Use proper HTTP status codes: HTTP status codes were defined for a reason, and they form a standard set of rules that most systems on the web follow.
So we should use proper HTTP codes in our APIs and servers.
If it’s a success return 200, if it’s a redirect return 302 and if it’s not there, return 404.
This enables us to build more robust clients and servers.
Always use SSL/TSL: As I said, HTTP traffic is plain text so anyone or any system can read it.
To prevent this we should always use an SSL certificate to ensure that the request and response are completely encrypted and only readable to the intended client and server.
Use CSRF security: HTTP being stateless, we can’t ensure the validity of clients on servers.
So we should use a CSRF token or similar mechanism to prevent cross-site request forgery attacks.
Use JWTs for secure APIs: When building APIs the best way to grant secure access to clients are through JSON web tokens.
JWTs should be used with a secure algorithm and secret key.
Also, they should be provided in the Authorization header instead of browser cookies.
Originally published at https://alazierplace.
com on May 19, 2019.
.