My earlier blog post on caching requires some follow up. In fact, the utility of httplib2 or any other HTTP cache hinges on whether or not the server hosting the wanted resources provides validating (ETag or Last-Modified) or freshness (Expires or Cache-Control) headers. In other words: the organization running the server has to want to help you save bandwidth. The original blog post says "That function caches the result of WMS requests for layer legends in a dedicated directory, assuming that the images are not changing over time."
If I read the Linfinti blog post right, this is the kind of image they'd like to avoid fetching unnecessarily. If you look closely at a HTTP request for the legend image (passing the -v option to curl, with  standing in for the request in the code below), you see:
krusty-2:~ seang$ curl -v  > /tmp/legend.png * About to connect() to frameworkwfs.usgs.gov port 80 (#0) * Trying 184.108.40.206... connected * Connected to frameworkwfs.usgs.gov (220.127.116.11) port 80 (#0) > GET /framework/wms/wms.cgi?SERVICE=WMS&VERSION=1.3.2... HTTP/1.1 > User-Agent: curl/7.19.5 (i386-apple-darwin9.8.0) libcurl/7.19.5 OpenSSL/0.9.8k zlib/1.2.3 > Host: frameworkwfs.usgs.gov > Accept: */* > < HTTP/1.1 200 OK < Date: Thu, 18 Feb 2010 21:26:03 GMT < Server: Apache/2.0.46 (Red Hat) < Connection: close < Transfer-Encoding: chunked < Content-Type: image/png
No validator headers. No freshness headers. Neither httplib2 nor a HTTP caching proxy is going to be useful here. You're on your own. Hurrah for standards. Let a thousand ad-hoc caching schemes bloom.