[Http-crcsync] General comments on crcsync document

[Alex Wulms]

All,

I would expect a client to perform a standard GET request for it's first 
request to a server. A crcsync-aware server should then advertise it's 
capability in a response header so that the client can use a delta-request 
the next time that the user wants to refresh this resource.

Keep in mind that on the first request, the client won't have anything in the 
cache from this server; it is a first request after all... So there is no 
overhead at all in this approach (except for the small capability response 
header)

Obviously this is suboptimal at the moment that a non-crcsync-aware 
server -from which the client has already received normal responses- gets 
upgraded to a crcsync-aware server; the first request that the client will 
send after such an upgrade would still be a normal GETrequest. However, the 
now crcsync-aware server should at that moment announce it's capability so 
that the client can switch to delta-requests after all.

What do you think?

Thanks and kind regards,
Alex



Op donderdag 9 juli 2009, schreef 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
>
>
>
>
> _______________________________________________
> Http-crcsync mailing list
> Http-crcsync at lists.laptop.org
> http://lists.laptop.org/listinfo/http-crcsync