We here at DOSarrest often run into questions posed about the differences between HTTP versions 1.0 and 1.1, so we have developed this article based on the specifications of each to try and clear up some of the more common questions and differences between the two specifications.
HTTP/1.0 was officially introduced and recognized in 1996. Since then its popularity has been staggering.
Accounting for over 75% of internet backbone traffic, it has been a pillar for the development and growth of the Internet. HTTP1.1 development took over four years. As a result, there are numerous interim implementations resulting in many clients using version1.1 before the final specifications were finished. The final version therefore had to be compatible will all previous releases of 1.1 and 1.0
HTTP1.0 defined a limited number of status codes at 16. The need for better resolution reporting was obvious and version 1.1 introduced 24 new status codes to better define errors and failures. Version 1.1 introduced the “warning” header to carry any number of secondary status indications. The purpose of this being to inform the recipient that something may be substandard about a supposedly successful request. Warning codes are divided into two classes based on the first digit of the three digit code. One class of warning must be deleted after successful validation of a cache entry; the other class must be retained with a revalidated cache entry. This difference is made based on the first digit of the code instead of a comprehensive listing of codes making it extensible to warning codes defined at a future date.
HTTPv1.0 provides only basic authentication (challenge-response control), a major flaw with this method is that the usernames and passwords are unencrypted making them vulnerable to snooping, also they have no time dependencies. Therefore any information gathered by snooping can be used long after it was collected. HTTPv1.1 corrected this issue with the use of Digest Access Authentication, which mirrors basic authentication but allows the server’s challenge to use a one-time value. For a successful response the client must compute a checksum (default MD5) of the username, password, one-time value, HTTP request method, and requested URI. The password is not only encrypted but the particular response is only valid for a single specific resource and method.
HTTPv1.0 was designed to use a new TCP connection for every request; therefore each request suffered the cost of setting up a new TCP connection. Most web interactions are short and rarely get past the slow-start area so they fail to maximize their use of available bandwidth. Version 1.1 solved this problem with the use of persistent connections and pipelining requests on a persistent connection. While some version1.0 implementations used a “keep-alive” header to request a connection to persist, it did not operate well with intermediate proxies. Version1.1 makes persistent connections default, and servers, clients and proxies will assume a connection is kept open after transmission of a request and its response. Version1.1 does allow connections to be closed at any time but to manage resources effectively it’s obviously best to do this only after the end of a response. Although HTTP1.1 can transmit multiple requests over a solitary TCP connection, each request is required to be sent in one contiguous message. The server must still send responses for a specified connection in the order of the matching request, but a client does not need to wait for a response to its request before sending another on the same connection (pipelining) thus eliminating latency due to network round trips, making the best use of the TCP protocol.
There are numerous differences between HTTP1.0 and 1.1. While version1.1 is a vast improvement to its predecessor, the protocol description has tripled in length with many of the features introduced with no beta evaluation at all. Regardless, version1.1 is becoming the defacto protocol with webserver adminstrators.
DOSarrest Internet Security