Matthew Toseland wrote:
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 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?
The ETag generated should be sufficiently unique to prevent browser using wrong data from its cache for display.
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.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.
_______________________________________________
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
