Intermediate proxies

> Introduction

``Intermediate proxy'' means an HTTP proxy in the chain of rsync
encoded requests.  For example, we might have an rproxy on the user's
machine, a corporate firewall running an HTTP proxy, and an
accelerator on the origin server.

> Problem

The main concern here is that intermediate proxies don't cache the
rsync-encoded reply, thinking that it is the real thing.
Unfortunately we will probably have to work around dodgy ~1.0 caches.

> Cache-Control

Setting the Cache-Control header might be OK, but that will affect the
user agent's cache as well, which is a bit bad.

> Vary

Setting the Vary header to indicate that the response varies on the
Rsync-Signature header would be good.  I'm not sure if all old proxies
will understand it properly.  It's not mentioned in RFC1945.

> Encoding

Perhaps the proxy will be smart enough to realize 

> Different response code?

The delta-http guys decided that the only reliably thing to do was to
give a different HTTP response code, rather than 200.  Perhaps this is
a good idea, but it's pretty disruptive to the soul of the request.
Still, it's easy to put it back -- we know the original must have been
a 200 status.

They suggest using something like

  226 Update follows