[tahoe-dev] 'Client' caching?

David-Sarah Hopwood david-sarah at jacaranda.org
Sat Nov 28 04:59:41 UTC 2009


Brian Warner wrote:
> On Nov 25, 2009, at 11:45 PM, Nathan Eisenberg <nathan at atlasnetworks.us>
> wrote:
>>  My first instinct was to turn to Squid.
> 
> Hm, I'm surprised that didn't work. Do you know what caused Squid to
> believe the file was changing each time? Maybe a quick peek at the
> returned headers would be informative.
> 
> Basically, any URL that starts with /uri/URI:CHK: should be immutable
> and an ideal choice for caching. We'd planned (although I can't check
> right now to see whether we got around to implementing it or not) to add
> an ETag: header with the file's UEB header, which is basically a hash of
> the contents, and thus an ideal etag.

This code at line 365 of src/allmydata/web/filenode.py looks as though it
is trying to do that:

    if not self.filenode.is_mutable():
        # TODO: look more closely at Request.setETag and how it interacts
        # with a conditional "if-etag-equals" request, I think this may
        # need to occur after the setResponseCode below
        si = self.filenode.get_storage_index()
        if si:
            req.setETag(base32.b2a(si))

using the base32 encoding of the storage index as the ETag (which seems
reasonable).

I'm not familiar enough with twisted.web.http, or with HTTP caching, to
tell whether it is handling the caching-related HTTP headers correctly.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20091128/f36f851e/attachment.asc>


More information about the tahoe-dev mailing list