Robert Bihlmeyer wrote: >>Also, HTTP/1.1 requires that any compliant server includes Date header >>with all responses (unless the server is clockless). >>(http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.18 ) > > Yeah. But fixing that is pretty low priority for me until you show me > that it breaks something other than a spec (e.g. a real client). We do > include Date in /some/ responses.
The fix should be oneliner and it needs to be done anyway for proper caching support. One can't tell what will happen with different browsers/readers (excluding IE which doesn't care what kind of garbage you feed it with) and caching behavior if the spec is broken. > In a related vein, DNF and friends should perhaps be 404s. IIRC they already are.. > My current caching target are the web interface images (and static > pages), as these make most sense to cache. For freenet content, I > don't know, we may actualy want to actively prevent caching. Making the 304 response work for FProxy pages should fix its caching issues. ETag could be useful for actual Freenet content where you can't exactly tell the last modified date. Every content sent to the browser takes cpu and ties resources in FProxy thus should be avoided if possible. And if you want real life example, most browsers limit connections (and requests with HTTP/1.1 pipelining) to proxy/hosts and giving fast responses frees those connections for retrieving next content. If a page in Freenet has lot of seperate content (images), it takes somewhat long time to reload the page because FProxy has to process and send all the content again to the browser even if it was already cached. _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
