[Http-crcsync] General comments on crcsync document

[Alex Wulms]

Hi,

Using content-encoding gives issues with e-tag based classical caching in case 
of proxy-based crccache handling; the crccache will have to translate from 
the content-encoding of the origin-server to the crcsync content-encoding, in 
which case it should modify the e-tag (e.g. append ' crcsync' to the value) 
because the e-tag is associated with the 'entity' (being the encoded 
content). This will then prevent classical caching based on an e-tag where a 
server might otherwise have replied with a '304 not modified'  response.

The idea in the current specification is to make this transparent by 
remembering the original headers (e.g. content-encoding and e-tag) in the 
(first compressed) block of the delta-response-body and restoring them in the 
reconstructed page and obviously also re-encoding the reconstructed page so 
that the entity-coding and the e-tag match again.

But maybe this is indeed overcomplicating the whole stuff. After all, we are 
doing this project to accelerate access to dynamic sites for which the 
classical caching does not work well. So we could say: tough luck that 
responses get translated from 'gzip' encoded to 'identity' encoded in the 
process and can therefore no longer rely on the e-tag for a conditional 
request.

Cheers,
Alex


Op donderdag 9 juli 2009, schreef 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