Four parties communicate over HTTP in the rproxy protocol:

user agent decoding proxy encod proxy origin server

These parties may be merged in some cases: for example, decoding may be handled by code inside the client, or encoding by code inside the origin server. For the time being the most common configuration will have them distinct.

HTTP proxies may be interposed at any point. Complying HTTP proxies that do not understand the rproxy extensions will transparently pass through rproxy requests.

Client sends an HTTP request to a local rproxy. rproxy checks whether it has an old version of that document, or one like it, in cache. The local rproxy sends a `signature' of the old version across the Internet to a remote rproxy. The remote rproxy forwards the request to the origin server, which generates the content. The origin server returns the full content back to the rproxy. rproxy computes the differences between the signature of the old cached document and the new version. It transmits a compressed description of those changes back to the client's rproxy. The client's rproxy applies the change list to it's old cached copy, updates the cache, and forwards the regenerated document back to the client.

The result is that only a description of the old document and of the changes need be transferred across the slow network. The technique performs particularly well against web sites where the content is dynamically generated within an unchanging framework, such as news portals or bug-tracking databases.

When a server sends down an rsync-encoded file, it also includes the signature of that file as it should be returned to the server on future requests.

The prototype of rproxy left the responsibility for generating signatures with the client. This may cause patent problems, so the released versions generates signatures on the server.

If the client indicates that it can accept the ``rsync'' transfer-encoding, then the server can decide to send content back in that encoding. If the client has an appropriate file

The server might also be intelligent about deciding what files to encode. For example, PNG and JPG image files are already compressed, and probably (yet to be tested) don't often change in a way that rsync can handle. Therefore, the server can know never to send these files rsync-encoded, or to put a signature in them.

The server might also be able to cache signatures for resources that change infrequently: pages that are updated every day, for example.

In general the resource being sent by the server may be dynamically generated, so the server will not know its signature until it's seen the whole resource. Since the resource may be of arbitrary length.

It would not work well just to put the signature at the end, either: we want the client to be able to resume the transfer if it is interrupted part-way through.

Because signatures are always sent after the data they describe, the client always has at least as much data in its cache as it has signatures for. It should therefore be able to handle any response encoded relative to that signature.

Non-terminating responses should be handled OK by this approach.

It seems like the right place to put intelligence about signatures is upstream, and on the origin server if possible: it will know more than anyone about the structure and content of its resources.

The choice of Two binary formats are used in rproxy; both are carried within standard HTTP transactions. The rproxy signature is a digest of the file that supports generating differences; signatures are stored in the cache in the decoder.