[Http-crcsync] General comments on crcsync document

[Patrick McManus]

On Thu, 2009-07-09 at 05:39 -0700, Pedro R wrote:
> H
> Upon first contact, the client will never send a full "If-Block" header. It will only send "If-Block: 0", because 
> it does not have anything in the cache. So constructing the If-Block header does not have a cost in this
> situation.


What I am saying is that the server cannot construct a better response
with if-block: 0 than it could without if-block there at all. Indeed, if
there is nothing to diff against, delta isn't much of a strategy. I am
opposed to _requiring_ the server to ever do anything in the presence of
if-block - that's an implementation decision on the server side.
(coincidentally, the doc says "0" means 1 hash.. what hash are you
using?) That's mixing capability (advertisement) and execution again.

Advertise with an advertising response header. This can certainly be
sent even if there is no if-block in the request (see accept-ranges).
This is the kind of thing that can be meaningfully required to at least
a SHOULD level (noting that it might be cached).

If-block ought to be expensive because it ought to carry meaningful
information. It seems reasonable not to send one until you have seen
something like "accept-crcsync" in a response, but again that's an
implementation decision on the client side.. not something for the spec
to mandate.

OPTIONS is a bit of a red herring. If you want to explicitly probe then
that's the way to do it. If you don't want to probe I'm not saying you
have to! :)

Best Regards,
Patirck