[Http-crcsync] First contact with a crcsync server

[Patrick McManus]

On Thu, 2009-07-09 at 11:23 +0100, Gervase Markham wrote:

>  Then the server can send a normal response as a 
> set of compressed blocks as a way of saying "I know you don't have a 
> base for this, so the only benefit you'll get is the gzipping, but 
> that's good, and I'm also showing you I support crcsync. Do send me 
> crcsync-based headers in the future."

a 226 delta instance coding is less useful than a "200 OK,
content-encoding: gzip" response because such a response cannot, as
specified currently, be re-used by any proxies along the chain. IMO a
smart server would generate the 200 in response to the request you are
suggesting. (one without a matching hash)

don't mix capability and application. Announce capability in a
capability header (i.e. the same way accept-ranges or allow work) and
make it independent of application. If you do make a delta application
then I agree the capability announcement is redundant and can be
skipped.