[PLUG] squid: request from another cache as a client?

AthlonRob AthlonRob at axpr.net
Thu Oct 16 21:35:02 UTC 2003


On Thu, 2003-10-16 at 19:53, Paul Johnson wrote:

> On Thu, Oct 16, 2003 at 03:03:09PM -0700, Paul Heinlein wrote:
> > * will the site owner promise never to post his/her URL on
> >   Slashdot? :-)
> 
> Actually, this is less of a problem if people would just use proxy
> caches.  Speaking of which, anybody know how to make squid request
> from another proxy like a browser would?

A cache at the individual ISP level would be very nice, I agree... but
do most have such a thing available?  I know mine doesn't.

Public caches can't run as fast as a direct connection to the web server
because they're either free with limited resources or cost money - and
who wants to pay?

A cache at the LAN level isn't going to make a significant dent in
things.

So, if you don't mind, would you elaborate on your proxy cache idea? 
:-)

As for chaining squid, IIRC it is pretty easy.  Just looked it up in
squid.conf.default:

#  TAG: cache_peer
#       To specify other caches in a hierarchy, use the format:
#
#               cache_peer hostname type http_port icp_port
#
#       For example,
#
#       #                                        proxy  icp
#       #                                        proxy  icp
#       #          hostname             type     port   port  options
#       #          -------------------- -------- ----- -----  -----------
#       cache_peer parent.foo.net       parent    3128  3130  [proxy-only]
#       cache_peer sib1.foo.net         sibling   3128  3130  [proxy-only]
#       cache_peer sib2.foo.net         sibling   3128  3130  [proxy-only]
#
#             type:  either 'parent', 'sibling', or 'multicast'.
#
#       proxy_port:  The port number where the cache listens for proxy
#                    requests.
#
#         icp_port:  Used for querying neighbor caches about
#                    objects.  To have a non-ICP neighbor
#                    specify '7' for the ICP port and make sure the
#                    neighbor machine has the UDP echo port
#                    enabled in its /etc/inetd.conf file.
#
#           options: proxy-only
#                    weight=n
#                    ttl=n
#                    no-query
#                    default
#                    round-robin
#                    multicast-responder
#                    closest-only
#                    no-digest
#                    no-netdb-exchange
#                    no-delay
#                    login=user:password | PASS | *:password
#                    connect-timeout=nn
#                    digest-url=url
#                    allow-miss
#                    max-conn
#                    htcp
#                    carp-load-factor
#
#                    use 'proxy-only' to specify that objects fetched
#                    from this cache should not be saved locally.
#
#                    use 'weight=n' to specify a weighted parent.
#                    The weight must be an integer.  The default weight
#                    is 1, larger weights are favored more.
#
#                    use 'ttl=n' to specify a IP multicast TTL to use
#                    when sending an ICP queries to this address.
#                    Only useful when sending to a multicast group.
#                    Because we don't accept ICP replies from random
#                    hosts, you must configure other group members as
#                    peers with the 'multicast-responder' option below.
#
#                    use 'no-query' to NOT send ICP queries to this
#                    neighbor.
#
#                    use 'default' if this is a parent cache which can
#                    be used as a "last-resort." You should probably
#                    only use 'default' in situations where you cannot
#                    use ICP with your parent cache(s).
#
#                    use 'round-robin' to define a set of parents which
#                    should be used in a round-robin fashion in the
#                    absence of any ICP queries.
#
#                    'multicast-responder' indicates that the named peer
#                    is a member of a multicast group.  ICP queries will
#                    not be sent directly to the peer, but ICP replies
#                    will be accepted from it.
#
#                    'closest-only' indicates that, for ICP_OP_MISS
#                    replies, we'll only forward CLOSEST_PARENT_MISSes
#                    and never FIRST_PARENT_MISSes.
#
#                    use 'no-digest' to NOT request cache digests from
#                    this neighbor.
#
#                    'no-netdb-exchange' disables requesting ICMP
#                    RTT database (NetDB) from the neighbor.
#
#                    use 'no-delay' to prevent access to this neighbor
#                    from influencing the delay pools.
#
#                    use 'login=user:password' if this is a personal/workgroup
#                    proxy and your parent requires proxy authentication.
#                    Note: The string can include URL escapes (i.e. %20 for
#                    spaces). This also means that % must be written as %%.
#
#                    use 'login=PASS' if users must authenticate against
#                    the upstream proxy. This will pass the users credentials
#                    as they are to the peer proxy. This only works for the
#                    Basic HTTP authentication sheme. Note: To combine this
#                    with proxy_auth both proxies must share the same user
#                    database as HTTP only allows for one proxy login.
#                    Also be warned that this will expose your users proxy
#                    password to the peer. USE WITH CAUTION
#
#                    use 'login=*:password' to pass the username to the
#                    upstream cache, but with a fixed password. This is meant
#                    to be used when the peer is in another administrative
#                    domain, but it is still needed to identify each user.
#                    The star can optionally be followed by some extra
#                    information which is added to the username. This can
#                    be used to identify this proxy to the peer, similar to
#                    the login=username:password option above.
#
#                    use 'connect-timeout=nn' to specify a peer
#                    specific connect timeout (also see the
#                    peer_connect_timeout directive)
#
#                    use 'digest-url=url' to tell Squid to fetch the cache
#                    digest (if digests are enabled) for this host from
#                    the specified URL rather than the Squid default
#                    location.
#
#                    use 'allow-miss' to disable Squid's use of only-if-cached
#                    when forwarding requests to siblings. This is primarily
#                    useful when icp_hit_stale is used by the sibling. To
#                    extensive use of this option may result in forwarding
#                    loops, and you should avoid having two-way peerings
#                    with this option. (for example to deny peer usage on
#                    requests from peer by denying cache_peer_access if the
#                    source is a peer)
#
#                    use 'max-conn' to limit the amount of connections Squid
#                    may open to this peer.
#
#                    use 'htcp' to send HTCP, instead of ICP, queries
#                    to the neighbor.  You probably also want to
#                    set the "icp port" to 4827 instead of 3130.
#
#                    use 'carp-load-factor=f' to define a parent
#                    cache as one participating in a CARP array.
#                    The 'f' values for all CARP parents must add
#                    up to 1.0.
#
#
#       NOTE: non-ICP/HTCP neighbors must be specified as 'parent'.
#
#Default:
# none

The documentation in that file is nothing if not complete.  :-)

Rob





More information about the PLUG mailing list