Robert Bihlmeyer wrote:
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.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.
In a related vein, DNF and friends should perhaps be 404s.
IIRC they already are..
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.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.
_______________________________________________
devl mailing list
[EMAIL PROTECTED]
http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
