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

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; 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 - 09:32:30 MDT