[Http-crcsync] General comments on crcsync document

[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_deflate.c


Cheers,
Alex