Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Extend the HTTP protocol to allow differences between files to be handled, thus reducing data transfer, and speeding response time.

IP.com Disclosure Number: IPCOM000019694D
Original Publication Date: 2003-Sep-25
Included in the Prior Art Database: 2003-Sep-25
Document File: 3 page(s) / 62K

Publishing Venue

IBM

Abstract

A method for reducing HTTP protocol data flows by communicating differences between file versions, rather communicating complete files.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 36% of the total text.

Page 1 of 3

  Extend the HTTP protocol to allow differences between files to be handled, thus reducing data transfer, and speeding response time.

The technique disclosed has the potential to reduce the amount of data transferred between web servers and caching proxies/web browsers. This frees up network bandwidth, and increases response time to the end user.

    The technique disclosed involves extending the HTTP protocol by adding an extra header field "Version". This field is used both by the client and the server, but has a subtly different meaning for both. This new field allows the client and server to decide more intelligently than before what data the server needs to send to the client. In some cases, the server may decide that *no* file data needs to be sent to the client, which will dramatically improve response time, and reduce network load.

    As long as the client has some version of the file that it is requesting from the server, the server can often guarantee to return less data than the full size of the file, but the data returned will allow the client to reconstruct the full file precisely and reliably.

    A technique is disclosed to add an extension to the Hypertext Transfer Protocol version 1.1 (specified by RFC 2068, Network Working Group, January
1997) that allows more efficient data transfer by reducing the amount of data transferred.

    The technique disclosed is embodied by adding a new meta-data header field or "token" to both the client (request) and the server (response) ends of the communication line.

    This new header field specifies the version of the file that is being requested by the client, or sent by the server. This "file version" has a different meaning, depending on whether it is being specified by the client or the server. When the client contacts the server, requesting a file, it specifies the current version of the file that it already has. If it does not already have any versions of the file it is requesting, the version specified is blank. When the server sends the file back to the client, it sends the corresponding version number of the file. Note that the server will only ever send the latest (most current) version of the file.

    The file version field allows the server to decide more intelligently what data needs to be sent to the client (if indeed any data needs to be sent at all). Assuming the client already has a version of the file, and that when the client contacts the server, the server determines that the version of the file the client has is the most up-to-date, the server will return *no* file data, but it will return the same file version as sent by the client. This tells the client that it already has the latest version of the requested file.

    However, if the file on the server has changed, the server can construct the set of differences between the version of the file the client requested, and the latest version of the file, and only send those differences. The client, on receiving the reply from the serve...