[Http-crcsync] General comments on crcsync document

[Pedro R]

Hi Alex,


>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 
>he next time that the user wants to refresh this resource.

>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?

Sounds good. I don't think it is suboptimal in the case you just referred. Only 
the first GET would be normal, nothing special to take in consideration.

But let me a bit more specific. Assuming that the client already knows that the
server is crcsync capable, in the current implementation of the server there is 
no "Content-Encoding: crcsync" in the response header.

Is there any special reason for not having this header? Allow me to state my case.

I am pushing this Content-Encoding header because it will be easier and cleaner
to implement the client on a Firefox extension. The alternative is doable but not 
desirable, since it involves a patch to Firefox source code.
Having said this, don't take it as a personal desire just to have less work. I think
my arguments below are valid.

Using the Content-Encoding header will allow the reuse of existing gzip
and deflate mechanisms in current browser engines (I know that Internet Explorer has 
"Pluggable Protocols" which allow MIME type conversions - exactly how it is done in 
Firefox/Gecko). Webkit should have a similar mechanism, and so should have other 
engines.

Keep in mind that ALL browsers which use the Gecko layout engine will be easily extended 
the same way I'm extending Firefox (and there are a lot of them). This Content-Encoding is
the trigger which activates the automatic conversion to uncompressed text (given a filter which
decodes crcsync, of course).

I'm sorry to annoy you with this particular case, but the inclusion or not of this Content-Encoding
header is an important design decision in the client that I am currently coding!

Pedro Ribeiro



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