Matthew Toseland wrote: > >The CHK-string of content should do nicely. It would be better to use > >Last-Modified for FProxy's own content to minimize the amount of > >processing (we don't want to calculate hashes over and over for the > >FProxy content). > > Hmm. Why?
If you meant the Last-Modified, then I suppose the internal FProxy content could be returned with ETag header as the content is stored inside the .jar file and is not subject to change while the node is running. It was more like a general case of doing such with minimal amount of work (ie. figuring a modification date of static data in static environment usually does not cost much in processing). You could even use Expires to prevent any queries, but you would not want to set it too far into future if the FProxy content is going to change anytime soon. Take your pick. :) The ETag generated should be sufficiently unique to prevent browser using wrong data from its cache for display. > Uhm, if we provide Expires, the browser will use it, right? And then it > doesn't even have to revalidate until the expiry time? We don't want it > to revalidate until the expiry time. Of course browser will use it, but do we want to prevent browser re-querying the content until the expire time? Is it possible to tell beforehand when content will go stale? If yes, then Expires could be useful in those cases. Using too optimistic Expires with often updated content might prevent purging of stale content from the browser cache and transferring of updated content to Fred store. _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
