Hi Amos! > That is an entirely different problem to the one you have been talking > about so far.
For me it was all error pages (independent of if it is a DENY or anything else). > To replace just the page Squid is generating you do not have to > configure anything. Just remove all the installed > errors/*/ERR_BAD_GATEWAY translation files, and replace the > errors/templates/ERR_BAD_GATEWAY one with your custom static page. You > can optionally provide translated versions of your custom page too of > course. The problem here is that with this I cannot customize the response depending on which ICAP server is used or similar. It is again generic and in my reverse proxy case I cannot deliver different "error"-pages (irrespective of if it is an ACL error, or ICAP not working or...) depending on the vhost name that comes in... Maybe to clarify: We got 10 reverse proxy vhosts configured on the squid - most of which access different icap services behind it. Say: * http://a.b.c/... * http://d.e.f/... * http://g.h.i/... * ... These icap servers do typically And for each of those vhosts (a.b.c, c.d.e, g.h.i) I want to use a different set of error pages. So it would essentially need to deliver the following: errors/a.b.c/ERR_BAD_GATEWAY errors/d.e.f/ERR_BAD_GATEWAY errors/g.h.i/ERR_BAD_GATEWAY ... (depending on vhost) Same for ERR_ICAP_FAILURE, ERR_INVALID_REQ, ERR_INVALID_RESP,... The error_map seems to have provided some "logic" via the http://... Interface, that seemed usable. error_directory on the other hand only provides a single directory - if it had the "possibility" to use something like this: error_directory /opt/squid/error/%{HTTP:HOST}/ (or similar) or alternatively error_directory /opt/squid/error/<whatever>/ <ACL(s)> then it would work out of the box. But then I figured there is some other issue: If I have a trailing "http_access deny all", then I will not see any of the above "special" errors anyway (like ERR_ICAP_FAILURE when the icap service is down), because there seems to be the issue with this error still getting matched by the "http_access deny all" rule with no means to check on the response header... - I always just get to "ERR_ACCESS_DENIED" because of this match. So unless I remove this final "http_access deny all" rule I always get 403 response - when I remove it I get 500 with ERR_ICAP_FAILURE, but as I do not deny it I cannot apply deny_info. As I am still in the request phase - I cannot rely on an ACl checking for status 500 or similar (this information is not available yet during http_access) - so I am stuck (actually BEFORE we get to the error page issue that started all this)... In the end the deny_info only allows me to customize on the deny response, but not on the corresponding errors... Any ideas? Thanks, Martin P.s: # some ACLs: acl HTTP proto HTTP acl GETPOST method GET acl GETPOST method POST # imagine several of these blocks icap_service mib_request_XX reqmod_precache 0 icap://127.0.0.1:1344/XX/reqmod icap_service mib_response_XX respmod_precache 0 icap://127.0.0.1:1344/XX/respmod adaptation_service_set modify_request_XX mib_request_XX adaptation_service_set modify_response_XX mib_response_XX acl hosts_allowed_XX dstdomain "/file/with/list/of/vhosts.txt" http_access allow HTTP GETPOST hosts_allowed_XX adaptation_access modify_request_XX allow HTTP GETPOST hosts_allowed_XX adaptation_access modify_response_XX allow HTTP GETPOST response_adaption_XX # deny everything else http_access deny all # in the case of ICAP port being down this also matches and returns a DENY/403 Maybe I need a special ACL for such errors - but which would match? This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp
