Hi friends, today we are going to discuss about differences between HTTP 1.0 vs HTTP 1.1. However version 1.0 was successful and still getting used for many websites but there were few shortcomings in this version which were fixed in version 1.1. There were major improvements done in new version for performance, bandwidth consumption etc.
As we know that HTTP is application level protocol which works on top of TCP. Http uses TCP connections to transfer the data between client and server. If you are not much familiar with HTTP then you can check here.
Now let’s come to the difference between these two protocols. There is a long list of HTTP 1.0 vs HTTP 1.1. So I am breaking this study into multiple articles so that it’ll be easy to grasp each difference easily.
Let’s discuss about first difference i.e. Compatibility with older versions.
HTTP 1.0 vs HTTP 1.1 – Compatibility
Once version 1.0 was released, it took another 4 years to release version 1.1. In these 4 years many 1.1 drafts were released and people started using these. While working with these draft versions there were constantly issues, Improvement areas were reported and fixed also. By the time final version was released, there were many websites which were already working with few draft versions. However these draft versions were having issues but final version can’t ignore all these shortcomings of draft versions.
It was necessary to have final version compatible with HTTP 1.0 and all draft versions so that nothing should get break.
In addition to this, HTTP 1.1 was made in such a way so that it should be compatible with future versions also.
Couple of changes are listed below.
AS we know that each Http message has http version associated with itself. These version numbers are hop-to-hop, not end-to-end. For example, a client on Http 1.0 sends a request to a server which is on http 1.1. And this request is coming through multiple hopes in between. Client sent the request with http 1.0 in message but the hop which was just before the server was using http 1.1. So in this case when server will receive request, it will have http 1.1 in the request line.
There is no way for server to know the actual client http version.
To resolve this issue, a new request header was introduced as “via”. This header contains the path of HTTP version getting used in transmission. By this header server should be able to know the HTTP version of end client.
Below is the example of this header.
Via: 1.0 lazy, 1.1 p.example.net
HTTP OPTIONS method
HTTP/1.1 introduces the OPTIONS method, a way for a client to learn about the capabilities of a server without actually requesting a resource.
Below is the example of option request
Below will be the response
From above response we can see that server supports OPTIONS, GET, HEAD, POST methods.
Upgrading to other protocols
In order to ease the deployment of incompatible future protocols, HTTP/1.1 includes the new Upgrade request-header. 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.
The Upgrade header field is a HTTP header field introduced in HTTP/1.1. In the exchange, the client begins by making a clear text request, which is later upgraded to a newer HTTP protocol version or switched to a different protocol.
Connection upgrade must be requested by the client; if the server wants to enforce an upgrade it may send a 426 Upgrade Required response. The client can then send a new request with the appropriate upgrade headers while keeping the connection open.
This way a protocol switching happens.
In next session we’ll cover Caching improvements in HTTP 1.1