[Http-crcsync] General comments on crcsync document

[Patrick McManus]

On 7/8/09 10:23 PM, Pedro R wrote:
> What about another way: no crcsync headers are sent by the client, except for
> "crcsync" appended to "Accept-Encoding:"?
> When the server detects that a client accepts crcsync, it will send the crcsync
> block response.
> That way, the server is free to response in every way it feels apropriate and the client
> does not need to send any extra headers, saving a few precious bytes.
>      

Hi! It must be kind of late in Portugal, no?

I've got no problem with just sending if-block to any old server you 
know nothing about. You don't need to verify beforehand that it knows 
how to do this particular delta spec.  If we use the current spec 
terminology, I don't see the need for a new accept-encoding token to do 
so, though as a separate issue I do agree that it makes sense to talk 
about whether this should all be done with 
accept-encoding/content-encoding/vary instead of the way it is currently 
deined.

so you don't require OPTIONS in your implementation (either client or 
server). I agree. But you might _want_ to use OPTIONS to probe for 
deltas simply because creation of the If-Block header is conceivably 
pretty expensive. This is where the comparison with gzip breaks down.. 
adding the gzip request header is just a matter of appending a constant 
string, where the If-Block is considerably more involved - so you might 
want to know if the other end even understands it before you do so.. and 
yes, that can cost a round trip and still be a worthwhile endeavor 
(especially if you can reliably cache and reuse the result). I think 
"Expect: 100-continue" is kind of a similar thing.

meanwhile as an alternative, you might define a response header similar 
to accept-ranges which would allow the server to advertise its support 
for deltas even on responses that do not contain them.. (i.e. it means 
"I can do deltas" not "this is a delta") this eliminates the need for 
either probing with options or having the client proactively computing 
if-block lists (which hit the server side cache) on the first request 
submission while maintaining the separation between capability and use. 
(the key difference between accept-ranges and accept-encoding is that 
accept-ranges is a response header instead of a request header.. it is 
the only accept-* header that is a response header that leaps to mind.)

make sense?

-Patrick