HTTP 1.0 vs HTTP 1.1 – Bandwidth Optimization

Hi Friends, as part of “differences between HTTP 1.0 vs HTTP 1.1”, we are now trying to cover another important difference about HTTP 1.1 – bandwidth optimization.

Let’s discuss about http 1.1 – bandwidth optimization changes.

Bandwidth Optimization

As we know that bandwidth is precious to serve client better and efficiently. If we are not utilizing bandwidth in effective way then it may cause issues while transferring data. Inefficient use of bandwidth increases network latency which decreases site performance.

So we should be very careful to decide mechanism through which we can preserve bandwidth and can use in effective way.

Bandwidth improvement is also part of those key changes which were done in HTTP 1.1.

What was in HTTP 1.0

We were having few issues in HTTP 1.0 due to which there are higher chances to get bandwidth wastage.

Sending large requests to server:

Every server is restricted to accept requests up to specific sizes. If request is having size more than specification then server returns error code. But server returns error code after bandwidth is consumed by this large request. So this entire consumed bandwidth is a waste. There is no way in HTTP 1.0 so that client server can negotiate before sending large request.

Sending large responses to client:

There could be cases where client needs only a part of any big document or image but in HTTP 1.0 there is no way so that server can send only partial data. Server sends the entire data to client. This is another example of bandwidth wastage which could be saved.

Optimizations in HTTP 1.1

As we discussed about cases where client needs only a part of any big document or image. In HTTP 1.0 there was no way to achieve this but in HTTP 1.1 this is possible. Let’s discuss, how we can achieve this.

Range Requests:

By using this way a client can send a request and in the request it can mention a range to get. Once server processes this requests and if server supports range requests then server will transfer the range of bytes requested by client.

Following is the example of one range request.

In above example we can see that range from 0 to 1023 bytes is requested from server.

If a response contains a range, rather than the entire resource, it carries the 206 (Partial Content) status code. This code prevents HTTP/1.0 proxy caches from accidentally treating the response as a full one, and then using it as a cached response to a subsequent request. In a range response, the Content- Range header indicates the offset and length of the returned range, and the new multipart/byteranges MIME type allows the transmission of multiple ranges in one message.

Range requests can be used in a variety of ways, such as:

  1. To read the initial part of an image, to determine its geometry and therefore do page layout without loading the entire image.
  2. To complete a response transfer that was interrupted (either by the user or by a network failure); in other words, to convert a partial cache entry into a complete response.
  3. To read the tail of a growing object.

Expect and 100 (Continue):

Whenever client sends request to server, it includes Expect header with 100 status code. This request is just to get an approval about if client can continue or not. If server is fine with the expectations of client then it returns 100-continue response and client can continue. But if server does not meet the expectation then it can send any 4xx status code due to which client cannot continue with requests.

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.

A 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, or it will send a 417 (Expectation Failed) status if any of the expectations cannot be met.

This way server is able to save its bandwidth. If this would have been http 1.0 then this request would have transferred to server with entire body. Bandwidth is consumed and then server would have rejected the request which is complete waste of bandwidth.


In next articles we’ll discuss about few more differences between http 1.0 and 1.1.