[Http-crcsync] General comments on crcsync document

[Alex Wulms]

Hi Pedro,

It requires a few hours of focussed attention to make the changes, which means 
I would have to do it in a weekend. I should have time again in the weekend 
of 24 July. If that's not tool late for you, then I'm happy to make the 
changes myself.

Op maandag 13 juli 2009, schreef Pedro R:
> Seems OK!
>
> Glad we got it sorted then. Let me know if you need my help with the apache
> modules. I'll keep you posted on my progress with the Firefox
> extension/client.
>
> Pedro
>
>
>
>
>
> ----- Original Message ----
> From: Alex Wulms <alex.wulms at scarlet.be>
> To: Pedro R <eusou15 at yahoo.com>
> Cc: http-crcsync at lists.laptop.org
> Sent: Sunday, 12 July, 2009 18:50:47
> Subject: Re: [Http-crcsync] General comments on crcsync document
>
> Op vrijdag 10 juli 2009, schreef Pedro R:
> > What if instead of appending crcsync to the etag, the crccache server
> > would append the original encoding?
> >
> > (instead of etag-crcsync it would be etag-gzip for example).
> >
> > The client would store that modified etag and when it makes a request to
> > the proxy, the latter would make a regular conditional GET using the
> > original entity-encoding and the original etag.
> >
> > 304 not modified would work and there would be no need to store the
> > original headers in an extra block.
>
> That could work indeed as well. Though I would prefer to add something like
> crcsync-<original-encoding> and to explicitly use 'identity' when the
> original encoding was empty, so that crcsync-client can scan for
> crcsync-<original-encoding> without getting confused by transformation
> information added by apache's mod_deflate, which appends the performed
> transformation to the etag (mod_deflate appends "-gzip" when compressing
> and "-gunzip" when uncompressing). See
> http://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/filters/mod_defla
>te.c
>
>
> Cheers,
> Alex