On 26/03/2013 9:57 p.m., Martin Sperl wrote:
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)
I'm not acceping patches for new error page macros unless there is a
clear generic need for it. In squid-3 the plan is to migrate the error
page macros to the logformat codes which are a lot more flexible and
have better coverage of state information. It just has not been
completed yet.
(That is not to say you can't use it internally until the macro update
is done. Just that its very unlikely to get accepted upstream.)
Thanks,
Martin
-----Original Message-----
From: Martin Sperl
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.
Which is what I understood you wanted in the beginning. Since that is
exactly what error_map does.
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...
Yes, we are still integrating notes for sharing between most components
of Squid. This will be possible one the error page macros are merged
with logformat which already supports %note. But that is some time off.
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...
Amos
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
