Hi Amos!
I had a final ide, which works: Checking on the response header for squid
errors and matching them in the http_reply_access path...
acl ICAPERROR rep_header X-Squid-Error ERR_ICAP
http_reply_access deny ICAPERROR
BUT, I would have to do this kind of thing for EVERY possible error
(errors/template currently shows 41 such variations) - which would increase
processing overhead tremendously...
So if I would propose a patch for 3.2 that implements either:
* keeping an "older" squid error info on ACL match deny, that could get used in
the deny_info config as a new pattern - say %C "for historic error"
or
* allow several variables in error_directory to get selected? (this would be
potentially a variation on the" language selector" for error pages, but this
one seems to be a bit more complex and potentially could inflict collateral
damage)
Would you accept that? (I would tend towards the first, as it seem simpler
without a code-review)
Thanks,
Martin
-----Original Message-----
From: Martin Sperl
Sent: Dienstag, 26. März 2013 09:27
To: Amos Jeffries; [email protected]
Subject: 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; [email protected]
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
