In our previous blog, we explored the initial stages of client-server communication, where the client reaches the server, and a bridge is established through the TCP layer for efficient data transfer. However, this alone isn't sufficient to facilitate data exchange. Both the server and client require additional information about the request and response to proceed further.
Now, let's delve into the concepts that come into play once the connection is established.
After the bridge is successfully established between the two parties through the TCP layer...
The connection between the client and server is established by the TCP layer of both machines. Data are effectively transferred between them through this path, but a lot happens after this state between them for successful data transfer before the bridge is destroyed.
So what factors are needed? Why it is needed? Let's understand this by revisiting the example we used to understand the need for bridges (make a quick revisit to the previous post before proceeding further).
continuation of the example
Now that the bridge, essential for people to travel, has been built and established, the next step is for the server to understand the specific type of people(resources) needed by the client. These resources could be likened to different professions like doctors, engineers, or architects. This understanding enables the server to send precisely the type of resources (people) required by the client
so it is important to send some additional information to the server for effective transfer of data.
Here is how the client requests the server
Imagine the client's request to the server as a letter with three distinct parts. The first part of the letter acts like an introduction, where the client explains what they need/ store / remove or change.
The second part of the letter holds critical information. It specifies the type of resource required. This part is like the client mentioning whether they need a doctor, engineer, or some other specific professional.
Lastly, the third part of the letter contains any additional information that the client wants to include. While this information isn't essential, it can provide context or extra details to the request.
The server understands those needs and forms an appropriate response.
Does the client always only request resources from the server?
No.
client not only requests data they also provide resources or information to the server The user who submits a signup form which includes the email ID, and password is sent to the server and the client also specifies what type of additional data is sent.
Now will go through the technical terminology and then will try to understand it by some examples with the analogy
Now, let's dive into what occurs after the connection has been established, using the letter analogy we discussed above.
The letter in the analogy refers to the protocol the client used to request a server so let's find out it by breaking down the request made by the client to the server.
So by referring to the above image we found that the client used the HTTP protocol to request the server for the resources
As with the letter analogy, HTTP communication can be broken down into three main parts
Request Line: The request line is the first part of an HTTP request and consists of three elements:
HTTP Methods: Specifies the action to be performed, such as GET, POST, PUT, DELETE, etc.
GET - to get the resources from the server by the client.
POST - to give resources to the server by the client.
PUT - to change the resource.
DELETE - to delete the resource.
URI (Uniform Resource Identifier): Indicates the target resource or URL that the request is being made to**(''example.com")**.
Request Headers: The request header is a collection of key-value pairs that convey additional information about the request. Some common headers include
Authorization: Contains credentials for authentication. The server then uses these credentials to verify whether the client is authorized to access the requested resource or perform the requested action.
Content-Type: Specifies the media type of the request body (for POST and PUT requests). This is related to the third part of the HTTP
Accept: This tells the server that I will accept this type of resources
Like from the analogy of how the client requests certain types like a doctor, or engineer to the server, technically the HTTP also request the type of resources that can be served by the server over the internet likely as follows:
"text/html", "application/json", "image/png" etc.,
Request Body: The request body is an optional part of an HTTP request, primarily used with HTTP methods like POST and PUT. It contains data that the client wants to send to the server.
The Content-Type will tell the server what type of data is sent by the client.
Just like the request the server also sends back the response that includes three parts
Status Line: The status line is the first part of an HTTP response and includes the following elements:
Status Code: A three-digit numeric code that indicates the outcome of the request (e.g., 200, 404, 500).
Status Text: A brief textual description of the status code (e.g., "OK" for 200, "Not Found" for 404).
Response Header: Similar to the request header, the response header contains key-value pairs that convey additional information about the response. Common headers include:
Content-Type: Specifies the media type of the response body (e.g., text/html for HTML, application/json for JSON).
Response Body: The response body contains the actual data or content that the server is sending back to the client. The format and content of the body depend on the nature of the resource being requested and the server's response.
Now lets understand this completely by real time example the http protocol
Client request google.com
Step 1: Client finds the ip address and reaches the server.
Step 2: A TCP connection is Established between the client and the server.
Step 3: The server process the request from client
Steps 4:The server responds back to the client based on the request.
Step 5: Connection closes.
The image below illustrates the client's request and how the server responds in the requested format upon receiving the request.
Now that we have a clear understanding of what occurs after the connection is established and how the server processes requests and responds to the client, let's revisit a question from our previous blog:
What if we could create a bridge that couldn't be broken? In other words, is it possible to prevent the TCP connection from being closed?
Indeed, it is possible to maintain an open connection. This is achieved using a specific header known as "Connection." When the server intends to keep the connection alive and doesn't want to close it, it includes the "Connection: keep-alive" header in its response to the client.
Conclusion:
In conclusion, we've journeyed through the intricacies of HTTP headers, understanding their significance in communication between clients and servers. These headers play a crucial role in conveying information, managing connections, and specifying content types. A solid grasp of HTTP headers is fundamental when working with web applications and APIs. As we continue our exploration of web technologies, we'll delve deeper into related topics to broaden our understanding further.