Nowadays, the Web is a chaotic environment, with many frameworks, plugins, protocols, libraries, etc. All of these tools are constantly changing; when you think you have mastered one of them, you find out that a new version has been released or that your previous work is already obsolete. Amid all this chaos, one protocol has been around since the beginning and probably will be for a long time. Created between 1989-1991 and established as a key standard for more than 20 years, I present the HTTP protocol.
Introduction
On August 6, 1991, one of the great revolutions of the internet began. When the computer scientist Sir Tim Berners-Lee published the first-ever web page as a publicly available service, the site was about the World Wide Web and how to make use of it. The page was hosted on Berners-Lee’s computer and supported by one of the world’s largest and most respected laboratories, the European Organization for Nuclear Research (CERN).
This historical milestone wouldn’t have been possible without one of the oldest protocols on the internet, the HTTP protocol. This article commemorates the 30 years of the first web page, describing the operation of this protocol that gave life to everything we know today about the internet.
What is the HTTP Protocol?
HTTP is the acronym for HyperText Transfer Protocol. It was created to transfer HTML files between computers in a laboratory environment. Since then, it has evolved; nowadays, it’s used to obtain high-resolution videos, images, download software, etc.
HTTP is a protocol that is used everywhere there is a Web device. For example, for you to read this article, a series of HTTP commands had to be executed to bring your browser these lines of text, the colors of the web page, the images, the links … practically everything.
How Does the HTTP Protocol Work?
The HTTP protocol works on the Client-Server model. It’s a TCP/IP application protocol (information about TCP/IP in the following article TCP vs. UDP: Battle of the Protocols ). Currently, the standardized version of HTTP is 1.1, and it’s the one that we’ll describe here. In general, the operation of HTTP is as follows:
- The client device establishes a TCP connection with the server, usually on port 80.
- The client sends a request with HTTP syntax and waits for the server’s response.
- The server processes the request and sends the client a response that includes a status code and the requested data (if any).
- The client closes the TCP connection. Before the client closes the session, phases 2 and 3 can be repeated as many times as necessary.
HTTP Messages
HTTP messages are the form of communication between the client and the server. These are composed of information in ASCII format and include several lines, each separated by CRLF (carriage return, followed by line feed); that’s why these are human-readable. There are two types of HTTP messages:
- HTTP Requests: Messages sent by the client. These include the information necessary for the server to analyze the request and understand what the client is asking for.
- HTTP Responses: Messages sent from the server in response to HTTP requests. These contain the request’s status and include data that comply with the client’s request.
Both types of HTTP messages share a structure. This format is shown in the image to the right.
- Start-Line: Identifies the start of the HTTP request or response. The request contains the type and origin, and the response includes the status code and message. Both have the HTTP version used.
- Headers: These allow the exchange of additional information between the client and the server. Union of the Start-Line and Headers are known as Head.
- Empty-Line: Indicates the end of the meta-information.
- Body: Contains the data sent or received. Also known as the payload.
HTTP Request Messages
These are the messages sent by the web client (also known as User-Agent), such as a browser. These messages tell the server what action to take and thereby determine the required response. An example of a request message is shown in the figure below.
Start-Line
The Start-Line is made up of three parts:
- HTTP method: Also called HTTP verbs (although there are some nouns among them), indicate to the server what action to take for that request. Some of the most commonly used verbs are shown in the table below.
- Origin: Relative path of the server resource. It can also include some queries represented by the ‘?’ symbol. In the example above, it is /posts.
- HTTP version: It tells the server the format of the message. The standard is HTTP/1.1, as is shown above.
Headers
Optional values that give the server additional instructions on how to handle the request. The structure of a header is as follows:
Case-insensitive string:value
These can be classified into three types:
- Request / Response headers: Describe additional information about the requested resource or unique characteristics that the client/server requires, such as user identification using tokens or cookies or the content types that the client can understand.
- Representation headers: Describe information about the body, such as data compression, encoding, etc.
- Payload headers: Contain information about the payload, such as the length of the data or the encoding used.
Body
Not all requests require the body field. It’s used to send data to the server to create new resources or update existing ones.
HTTP Response Messages
These are the messages sent to the client by the server. These have the same structure as the request messages, with the only difference being the Start-Line. An example of a response message is shown in the figure below.
Start-Line:
It’s known as the Status-Line, and it’s divided into three parts:
- HTTP Version: Usually HTTP / 1.1
- Status code: Notification if the request was successful or failed. In general, the error codes are divided into the groups presented in the table below. The complete list of status codes is at the following link, HTTP Status Codes.
- Status text: A purely informative short text message that helps humans understand the status of the message.
The HTTP Protocol and NetBurner
NetBurner would only be “Burner” if they didn’t support the HTTP protocol. Below you can find the relevant examples for NNDK version 3.x.x.
Server-Side Examples
Web server: These examples can be found at the path, \nburn\examples\Web. Here, you’ll find examples of serving embedded web pages and handling GET and POST requests.
Secure web server: In the directory, nburn\examples\SSL\SslWebDemo, you’ll find an example of how to start a secure web server that serves pages over a TLS connection.
Web server using EFFS-FAT: In the directory, \nburn\examples\EFFS\Fat\HTTP, you’ll find an example of serving a web page hosted on external SD memory and accessing the files inside it is using the path /DIR.
Web server using EFFS-STD: In the path, \nburn\examples\EFFS\Std\HTTP, you’ll find an example of how to serve files located in the flash on-chip file system.
Configuration Web server: In the path, nburn\examples\Configuration\Web, you’ll find some examples of how to use and customize the configuration server hosted on port 20034.
Client-Side Examples
Web Client: In the directory, \nburn\examples\WebClient, are examples of making GET and POST requests to servers hosted on the internet using auto-execution and straightforward tasks.
Secure Web Client: In the directory \nburn\examples\SSL\SslGetHttps, you’ll find and example of how to create a HTTPS request to a server. And in \nburn\examples\SSL\SslClientVerifyPeerBasic and \nburn\examples\SSL\SslClientVerifyPeerEffs you have two examples of how to use peer verify with SSL/TLS.
Serial to HTTP: This is an example of a GET request sent through the serial port, used for serial to Ethernet applications. It can be found in the directory \nburn\examples\serial\SerialHttpGetRequest.
More Information
- HTTP was born to work as an application protocol for TCP, but SSL/TLS can replace it, making it HTTPS. HTTPS encrypts data being sent back and forth between the client and server and provides a mechanism to ensure that both parties in the connection are who they say they are. Using HTTPS to serve the web content is strongly encouraged. (<! Add here references to SSL articles > )
- HTTP is a stateless protocol. It doesn’t save session information either in the client or the server; you can solve this with Cookies or Tokens. Both are sent as a Header and allows the handling of sessions.
- Currently, the HTTP protocol is directly related to the term REST (or REST-API, or RESTful API). REST is a set of rules and guidelines that allow data exchange between client and server using HTTP. The application defines these rules (that is, the rules can be unique for each application), making it very versatile for IoT applications and web systems.
- There is another term call GraphQL. It is a query language that replaces REST in applications which require versatility in the data obtained. Unlike REST with GraphQL, you can choose strictly which information fields are required on the client-side.
- Today, there is HTTP/2, which, unlike version 1.1, is no longer human-readable. In other words, it uses binary messages, which increases the optimization of network resources. It can handle multiple requests at the same time, as well as providing many other features. Although many sites are using this version, it is currently not as widely adopted as version 1.1.
Useful Links and Resources
We recommend the Mozilla developer docs covering the protocol found here, for a more in-depth look at HTTP.
Wrapping Up
Hopefully, this little guide helps all those developers who are beginning to venture into the world of the Web. As Tim Berners-Lee said, “When something is such a creative medium as the web, the limits to it are our imagination.” We’d love to hear some ideas of products or articles you would like to see using HTTP or other tools or technologies in the comments below.
If you have any other questions or concerns, don’t hesitate to send us a direct message at sales@netburner.com.
About the Author
Jordan Garcia. IoT and industrial protocols engineer at Racom Microelectronics.
Dog lover, bookworm, and sweet tooth. Fan of embedded systems, back-end and front-end development, and a constant joy in learning new things. Unique ability: to finding bugs in systems.