HTTP and “Package Response”

This is a technical post and is probably worth skipping if you don’t have a background in IT.

The HTTP protocol is moderately efficient at single transmissions that it was originally designed for, such as the HTTP GET requests that are used to retrieve a web pages HTML source.  However, this moderate efficiency is signficiantly reduced by the actual behaviour and semantics of website content and browsers.

Note: I have no idea whether the issues in this post have been previously debated.  A rudimentary search on Google and the W3C’s archives have not resulted in any significant content.  Please let me know if you know of any such discussions and I’ll link them here.

The problem

A single HTTP GET request, such as used when accessing a web page for the first time involves the following main sequence of events:

  1. The initiation of a connection to a remote server using TCP/IP
  2. The production of a HTTP GET request message, wrapped in TCP/IP packets
  3. The sending of the message to the remote server
  4. The parsing of the request by the remote server
  5. The processing at the remote server necessary to answer the request
  6. The construction of an appropriate HTTP response message, wrapped in TCP/IP packets
  7. The sending of the message to the client (browser)
  8. The processing of the HTTP response by the client
  9. The closing down of the TCP/IP connection

Typically (1) and (9) are very expensive operations in terms of latency and processing effort.  Therefore, the HTTP protocol permits a header known as a “keep alive” to indicate to the remote server that the TCP/IP connection should remain available for future requests.  This is very important as even the simplest web pages routinely have 10s or 100s of additional resources that must be retrieved in order to display the web page.  These include images, style sheets, script files and dynamic content.  However, HTTP “keep alive”s are not helpful in improving the performance of other operations in the sequence.

As computers have become more powerful and the Internet bandwidth available to individual user has also increased, two aspects of this pattern have changed:

  1. Web site editors have developed richer web pages relying on more and more secondary resources
  2. The proportion of time spent in network communication has increased (bandwidth has increased but network latency is at least as significant for the initial view of a web page)

To reduce the proportion of time spent in communication activities, web site developers and network managers are introducing additional complexity to address perceived performance issues:

  1. Splicing multiple images into a single file and using CSS to display only part of the image
  2. Compressing files using custom Javascript code to reduce the number of packets transmitted
  3. Providing sophisticated caching behaviours to segregate content that can be locally cached effectively and content that is more variable
  4. Introducing network caching layers such as edge caches (such as provided by Akamai Technologies) and ISP and corporate proxies

However, each of these introduces significant complexities:

  1. The editor has to create a single image file that includes multiple images.  This complicates version management of a single image (either requiring batch processing or manual version control of the compound file).  It also requires that the browser supports the necessary CSS styles
  2. Compressing files in Javascript code requires the use of code that supports no other purpose.  This isn’t a good use of Javascript (although effective) and puts a burden on the web site owner to manage an unreadable, compressed script file
  3. Caching behaviours can create real complexities in web site development

The reason that a solution is needed at all is that first impressions of a website count.  As it is not atypical for a user to have a network latency to a source server of 80-100 milliseconds, more than one roundtrip to the server is a noticeable delay.  The question is, could this behaviour be improved?

A possible solution?

One possibility would be the extension of the HTTP request and response messages to include the concept that a response to one URL is related to a set of other URLs.  This could be achieved by the addition of custom HTTP headers, ideally to be approved by the W3C as a formal addition to the HTTP protocol.  The approach outlined below is fully compatible with earlier HTTP protocol implementations.

First time request

  1. The initiation of a connection to a remote server using TCP/IP
  2. The production of an HTTP GET request message, wrapped in TCP/IP packets
    • The message includes a header indicating its support of a “Package Response”
  3. The sending of the message to the remote server
  4. The parsing of the request by the remote server
  5. The processing at the remote server necessary to answer the request
    • The server recognises the “Package Response” header in the request
    • As well as producing the standard output of the requested URI, the server also provides additional content parts (such as in a MIME or SOAP message) for a list of dependent resources (defined on the server)
    • Each of these content parts can have its own set of HTTP headers, the only distinction is that no additional HTTP request messages are sent to intiiate the sending of the corresponding response
  6. The construction of an appropriate HTTP response message, wrapped in TCP/IP packets
    • This includes an HTTP header indicating that the response is a “Package Response”
  7. The sending of the message to the client (browser)
    • Note that the server doesn’t have to buffer all the content before sending data back to the client
  8. The processing of the HTTP response by the client
    • The client processes the main response of the server, as usual
    • The client continues to receive the related resources
  9. The closing down of the TCP/IP connection

This approach could easily remove multiple rountrips to the server, especially where Javascript libraries are used as these often have to be loaded before the page can be rendered at all (or else the presentation is undesirable).

Subsequent requests

For subsequent requests, the client can send information about the state of the package as last received, including expiration information, and the server can give a response sufficient to answer the whole package request, rather than checking the state of each resource individually.


What do you think?  Would this be useful?  Is it a non-issue?  Comments welcome.

4 thoughts on “HTTP and “Package Response”

  1. Nguyen Trung Chinh


    Do you think that we are putting the burden of processing on server instead of spreading that out for browsers?


    1. Steve Horsfield Post author

      Yes, it is putting some additional burden on the server. However, this burden only applies to requests that are specifically asking for a “package response” although the server software (and the browser) need the software.

      Most importantly though, the burden of making these additional responses is offset by the need to handle and parse multiple incoming HTTP GET requests. My gut feel is that it would improve server scalability and predictable performance management, but I don’t have any statistics to support that view!

      Anyone else have some thoughts?

      (I’ve also asked this question of the LinkedIn “Linked .NET Users Group (LIDNUG)” group. You can see their responses if you are a member of the group)

  2. Steve Horsfield Post author

    Following further discussion, the following links are useful background information:

    W3C HTTP-NG Working Group ending 1998 (

    W3C HTTP Extensions ( moved to Experimental RFC ( in February 2000. Patches for Apache 2

    Discussion paper 24-June-1997

    I’ve not been able to find any current work or any direct comparison with this suggestion (so far). However, some of the work does describe multiple content parts in a response, but this is intended as a response to a single resource only.

  3. Bas Groot

    Principally, HTTP 1.1 works like that: it keeps the connection open for a while and streams more requests through it. But it waits. Let’s extend that a little.

    This idea could be useful, if it’s the browser that composes the compound request. Typically, it would go like this:

    browser request 1 contains a single, normal pageview. It’s HTML and sees some CSS and images that are not yet cached by the browser, like extrastyle.css, xyz.gif and qwerty.jpeg.

    So the browser issues request 2, that goes like:
    GET extrastyle.css HTTP\3.0|GET xyz.gif|GET qwerty.jpeg…

    And the web server would respond with a package response like you described, containing all the needed content crammed in one stream response with no waiting.

    The efficiency gained is that the web server does not have to wait for each request, and avoiding all timing overhead that comes with separate requests over a single socket like HTTP 1.1 and avoiding the use of extra threads and sockets to overcome all this asynchronous waiting.

    In effect, this will get the requests out faster and use less sockets per client for a shorter time.

    Furthermore the web browser could intelligently improve performance by putting the requests in a specific order that gets the best perceived browser rendering speed.

    I think it’s important that the web server determines what it wants to GET, to avoid transmitting unnecessary data that is cached already, and what’s cached known only to the web server.

    This means that it takes both more newer browsers and newer modern web servers to work, and may cause a chicken-egg adoption curve much like IPv6, but the benefits can be huge.

    Compression typically yields marginal results, because the bulk of the data is images and they are compessed already. If a site is well built in W3C compliant XHTML, HTML and CSS are usually quite small.

    And compression adds time, indeed with JS, it is of no use compressing. For example, we found that uncompressing the MooTools library takes so much time, that it is 3 times slower than just downloading the uncompressed version.

    Still, if the compression is done at the web server and uncompressed at the browser at socket level, and is geared towards a light LZW compression on only the text parts of the multi-request, it could make a big difference. Especially for large webbased content like large tables, big sitemaps, extensive portals or a complex web application.

    And even then, most world internet bandwidth is gobbled up by spam and video streams anyway, so it’s not the providers but the the web site owners and web site builders that would be the main supporters for such an improvement.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s