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

From: Martin Sperl <Martin.Sperl_at_amdocs.com>
Date: Tue, 26 Mar 2013 07:28:31 +0000

Hi Amos!

I hear what you are saying (especially about the http_response_access), but:

The thing with the config I have sent is that as soon as I have icap-service down the "http_access deny all" triggers and I get Status 403 plus in the body: "you are not allowed to access".
But with this "http_access deny all" removed/commented out - I get Status 500 instead plus the corresponding error message "trouble with ICAP" in the body.

So your explaination that http_access gets handled BEFORE icap gets called is not (100% true), as otherwise I would see the 500 error in both cases.
Thing is that it might get evaluated a second time on an error condition and then with modified Request data and then the ACLS do no longer match...

Another observation is that if I have conditional logging enabled (based on ACLs) then the respective 403 by the DENY all does NOT get logged to that file thus another indication that something strange happens to those ACLs on an ICAP error.
        
I will try to enable the debug logging on "full" and will report on the ACL matching that happens whe icap is down...

Ciao,
        Martin

P.s: Here again (relevant parts of ) the config:
# 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 - the final line
http_access deny all # in the case of ICAP port being down this also matches and returns a DENY/403 instead of 500 - remove this line and I get 500

-----Original Message-----

* ICAP errors *do not* map directly to HTTP errors. Usually one 502
means *multiple* ICAP services are havign problems - posisbley very
different problems. Trying to make one error page which represents *the*
issue ... results in "502 Bad Gateway".

* http_access is all tested well before ICAP gets involved. So this is
the wrong place to integrate anything about status codes however you
slice it.

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 Tue Mar 26 2013 - 07:28:43 MDT

This archive was generated by hypermail 2.2.0 : Tue Mar 26 2013 - 12:00:05 MDT