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

Stupid me - I forgot the following ACLs:
acl error500 http_status 500
http_reply_access deny error500
(but I had removed the deny_info "" error500 component).

And that http_reply_access triggers a reset of the previous ICAP_ERROR and moves it to ACCESS_DENIED instead...
Removing the http_reply_access I get the expected error 500 while retaining the "http_access deny all"

Which in the end means that squid is generating the error pages twice(as seen in the debug log) - once for the ICAP and then for the ACCESS_DENIED on response-delivery.

So this means that using the "deny_info" trick as above essentially makes us lose the info on the icap error - with no means to recover it.

OK, the debug.log shows that ICAP writes a note, but as there are no ACLs that allow for triggering on notes, it does not help either.
Nor is there an ACL that could match on those error fields that we could use instead...

So in the end means I have no means to identify the error with the deny_info, so I am left in a state where I cannot modify the redirect to include the root-cause and modify the page based on that...

Any more ideas, besides a patch to help achieve what I need? I think I now have covered everything that is possible (and learned a lot in that phase) as well...

Martin

-----Original Message-----
From: Martin Sperl
Sent: Dienstag, 26. März 2013 08:29
To: Amos Jeffries; squid-users_at_squid-cache.org
Subject: RE: [squid-users] squid 3.2 and error_map equivalent

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

-----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 - 08:27:31 MDT