DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=43838>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43838 ------- Additional Comments From [EMAIL PROTECTED] 2008-01-28 17:24 ------- Referring to http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html section 10.3.5 304 Not Modified "If a 304 response indicates an entity not currently cached, then the cache MUST disregard the response and repeat the request without the conditional" Reading the RFC, suggests that no matter what, if the image isn't in cache it should be requested. Our deployment is an offsite image-cache, with 1Gb connection to internet. With our hack, I tend to agree with the concerns of large files (wheter modified or not) being repeatedly requested from the backend should the cache server decide not to cache it due to CacheMaxFileSize or some other reason. The sites that are reverse proxied don't have large image files and represent ~95% of our traffic, the other remaining sites that may have large images are not proxied - the traffic goes over our 10Mb link, versus 1Gb at ISP. In general, the hack works for us, but don't want to be maintaining the code on an on going basis. Is there any work being done on this? Thanks Alec -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
