RE: [squid-users] squid 3.2 and error_map equivalent

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
Received on Mon Mar 25 2013 - 14:21:14 MDT