Hello friends, as we know that we are in the world of internet where each and every information is accessible from various servers upon requests. This communication mechanism is a complete picture where multiple components are involved to send request to server and get the response to you. You can have a look into the complete flow here.
In this complete flow, Http is one of the most important part which we need to focus upon. Http is meant for hypertext transfer protocol. HTTP is the foundation of data communication for the World Wide Web.
HTTP functions as a request–response protocol in the client–server computing model. A web browser, for example, may be the client and an application running on a computer hosting a website may be the server. The client submits an HTTP request message to the server. The server, which provides resources such as HTML files and other content, or performs other functions on behalf of the client, returns a response message to the client. The response contains completion status information about the request and may also contain requested content in its message body.
There are many type of responses which server can return. As developers we need to have information about meaning of each response code returned from server. Based on these response codes, you can narrow down troubleshooting to get the actual root cause of any issue.
I’ve divided this discussion into multiple parts based on the type of response codes.
So let’s start with the part – 1 where we are going to discuss about all those responses which are like 1xx e.g. 100,101 etc.
This response is just to inform client that it can continue to send remaining request. Server notifies client that it has not rejected its request. Once client receives this response code then client can send remaining request based on this response.
Let’s consider one example:
Assume that we have a client which want to transmit a video file to server. This file length may be high and server may not be able to process. To check if this file length is acceptable by server or not, client sends a request with expect header (Read more about Expect header here ).
Client sends a request with Expect header and waits for the server to respond before sending the message body.
PUT /somewhere/fun HTTP/1.1 Host: origin.example.com Content-Type: video/h264 Content-Length: 1234567890987 Expect: 100-continue
The server now checks the request headers and may respond with a 100 (Continue) response to instruct the client to go ahead and send the message body, else server will send some error code to reject the request.
If server approves the request and send 100 response code then server must send a final response after the request has been completed.
In order to ease the deployment of incompatible future protocols, HTTP/1.1 includes the new Upgrade request-header. This feature is part of compatibility. By sending the Upgrade header, a client can inform a server of the set of protocols it supports as an alternate means of communication. The server may choose to switch protocols, but this is not mandatory.
If server choose to switch protocol then it send 101 response header which notifies client that server is ready to switch protocol.
The server will switch protocols to those defined by the response’s Upgrade header field immediately after the empty line which terminates the 101 response.
The protocol SHOULD be switched only when it is advantageous to do so. For example, switching to a newer version of HTTP is advantageous over older versions
The 102 (Processing) status code is an interim response used to inform the client that the server has accepted the complete request, but has not yet completed it. This status code SHOULD only be sent when the server has a reasonable expectation that the request will take significant time to complete. As guidance, if a method is taking longer than 20 seconds (a reasonable, but arbitrary value) to process the server SHOULD return a 102 (Processing) response. The server MUST send a final response after the request has been completed.
Methods can potentially take a long period of time to process, especially methods that support the Depth header. In such cases the client may time-out the connection while waiting for a response. To prevent this the server may return a 102 (Processing) status code to indicate to the client that the server is still processing the method.
It is common for HTTP responses to contain links to external resources that need to be fetched prior to their use; for example, rendering HTML by a Web browser. Having such links available to the client as early as possible helps to minimize perceived latency. So there is a new status code i.e. 103 that lets the server send headers early, before the main headers. This helps with optimizations like preloading.
Example from the document:
HTTP/1.1 103 Early Hints Link: ; rel=preload; as=style HTTP/1.1 103 Early Hints Link: ; rel=preload; as=style Link: ; rel=preload; as=script HTTP/1.1 200 OK Date: Fri, 26 May 2017 10:02:11 GMT Content-Length: 1234 Content-Type: text/html; charset=utf-8 Link: ; rel=preload; as=style Link: ; rel=preload; as=style Link: ; rel=preload; as=script
There are various security risks with sending multiple headers to non-conforming clients hence a server might refrain from sending Early Hints over HTTP/1.1 unless the client is known to handle informational responses correctly.
That’s it about http response codes 1xx. In upcoming articles we’ll discuss about next set of codes.