Nagy Attila wrote:
> - store all files fetched direct or from the parent locally and if a
> request made for them, provide them to the clients from the disk
That is the default unless you use proxy-only cache_peer option, or the
no_cache configuration directive.
> - only go direct if the parent is dead
This mode of operation will be available in 2.2. Until then the closest
you can get is to mostly go by the parent, or always go by the parent
and fail when it is dead. As long as the parent is alive it should
however only go direct on "uncacheable" requests where it is of very
limited use to go by a parent (only adds latency).
> - if the parent is up use that (but not the above proxy-only mode:(
no-query is defenitely not the same as proxy-only. These are two
separate options, affecting different parts. no-query stops the use of
ICP queries, proxy-only stops local caching of objects fetched from the
peer.
It is possible that you are getting confused by the most common source
to peering confusion, namely "uncacheable" request (or Pragma:
no-cache). Browsers makes uncacheable requests when you push the reload
button, or in some cases when you select a bookmark.
> Is it possible that the parent does not capable to handle icp requests
> made by my proxy?
If adding no-query made it use the parent, yes. And as I said, adding
no-query does not affect cachability.
> If is it the problem, how can i test if a parent has that
> capabilities?
There is a two perl script which can be used to simulate ICP queries in
the scripts directory (icp-test.pl and upd-banger.pl).
Received on Sun Mar 07 1999 - 14:53:42 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:45:10 MST