Re: FTP icons access problems in a hierarchy

What the person who previously had a similar problem did was to allow
all users access to the icons on the 1'st level caches.

acl icons urlpath_regex ^/squid-internal-static/icons/

Then insert a
http_access allow icons
somewhere before the rule which denies access, or restrict the denial to
!icons like
http_access deny !peers !icons

There are a couple of known cases where a browser may bypass the normal
hierarchy flow for FTP icons:

a) There is a no_proxy setting which matches the domain of the Squid
where the FTP listing was generated.

b) The user has a locally cached a FTP listings page, and has disabled
proxy settings since the page was first fetched.

c) A PAC file is used which thinks that the Squid cache is "local" and
should be used directly

d) The downlevel cache has failed and the PAC file has DIRECT as backup
path.

--
Henrik Nordstrom
Spare time Squid hacker
Jens-S. Voeckler wrote:
> More or less, yes. The user got an access denied, because his browser did
> not have access rights to the toplevel cache. The 2nd level cache is a
> Roxen proxy, but only for some schemes. The 2nd level proxy does have
> access rights to the toplevel cache. I am afraid that the browser config
> is beyond my administrative reach