On Tue, 31 Oct 2000, Dr. Michael Weller wrote:
> Well, yes, my actual problem is I do not understand httpCachableReply()
> especially because it checks zillions of internal bits, whose meaning is
> unknown to me. I also do not want to change the caching of the other
> files. Where would I put my "return 1" in httpCachableReply()
> to deal only with this (or only a "little" more) case(s).
>
> That cache peer, btw, is not a real cache but a virus scanner. It really
> makes no sense to leave the caching to the peer here.
You can try this:
Index: http.c
===================================================================
RCS file: /squid/squid/src/http.c,v
retrieving revision 1.366
diff -u -r1.366 http.c
--- http.c 2000/07/18 06:16:41 1.366
+++ http.c 2000/10/31 18:46:42
@@ -255,6 +255,11 @@
case HTTP_MOVED_PERMANENTLY:
case HTTP_GONE:
/*
+ * hack
+ */
+ if (PROTO_FTP == httpState->request->protocol)
+ return 1;
+ /*
* Don't cache objects that need to be refreshed on next request,
* unless we know how to refresh it.
*/
The reason for the code commented with "don't cache objects from
peers w/o LMT, Date, or Expires" is from some problems observed in
a while ago in older Squid versions. Squid used to cache responses
that didn't have any timestamps. Such an object could "live forever"
in a sibling relationship. As soon as it got removed from one
sibling, it would be found again in the other sibling and then get
cached again for some default period of time. This continues
back-and-forth and makes it really hard to purge stale responses
from some hierarchies. So we added the requirement that if squid
gets something from a neighbor, it must have at least one timestamp
header so we know how long its been around.
-- To unsubscribe, see http://www.squid-cache.org/mailing-lists.htmlReceived on Tue Oct 31 2000 - 11:56:29 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:56:04 MST