[Http-crcsync] http-sync standard

[tridge at samba.org]

Hi Toby,

 > * Use the 226 response type to resolve the caching intermediate proxy
 > problem.

How would the 226 response type interact with existing proxies that
don't understand it?

I presume that proxies already know to not send encoded responses to
clients that didn't say they supported that encoding. So I imagine a
proxy already has to check whether the client said it supported gzip
encoding before it would send back a cached response that was gzip
encoded from an eerlier session. 

The delta-encoding case seems to be very similar. If the special 226
response type isn't universally supported yet, then another approach
would be to make the hashes part of the 'accept-encoding' string. For
example, we could have:

  Accept-encoding: rproxy-a5fe7652b265d073

where the hex numbers are a hash of the signature. That way dumb
proxies that only know what to do with mismatched encoding types would
correctly cache delta-encoded replies (the reply would be marked as
having the same string as the content encoding).

Or does the 226 response code somehow magically do the right thing
anyway with old proxies?

Cheers, Tridge