On 26/03/2013 3:21 a.m., Martin Sperl wrote:
Hi Amos!
That is an entirely different problem to the one you have been talking
about so far.
For me it was all error pages (independent of if it is a DENY or anything else).
To replace just the page Squid is generating you do not have to
configure anything. Just remove all the installed
errors/*/ERR_BAD_GATEWAY translation files, and replace the
errors/templates/ERR_BAD_GATEWAY one with your custom static page. You
can optionally provide translated versions of your custom page too of
course.
The problem here is that with this I cannot customize the response depending on which ICAP server is used or similar.
It is again generic and in my reverse proxy case I cannot deliver different "error"-pages (irrespective of if it is an ACL error, or ICAP not working or...) depending on the vhost name that comes in...
Maybe to clarify:
We got 10 reverse proxy vhosts configured on the squid - most of which access different icap services behind it.
Say:
* http://a.b.c/...
* http://d.e.f/...
* http://g.h.i/...
* ...
These icap servers do typically
And for each of those vhosts (a.b.c, c.d.e, g.h.i) I want to use a different set of error pages.
So it would essentially need to deliver the following:
errors/a.b.c/ERR_BAD_GATEWAY
errors/d.e.f/ERR_BAD_GATEWAY
errors/g.h.i/ERR_BAD_GATEWAY
...
(depending on vhost)
Same for ERR_ICAP_FAILURE, ERR_INVALID_REQ, ERR_INVALID_RESP,...
The error_map seems to have provided some "logic" via the http://... Interface, that seemed usable.
error_directory on the other hand only provides a single directory - if it had the "possibility" to use something like this:
error_directory /opt/squid/error/%{HTTP:HOST}/ (or similar)
or alternatively error_directory /opt/squid/error/<whatever>/ <ACL(s)>
then it would work out of the box.
But then I figured there is some other issue:
If I have a trailing "http_access deny all", then I will not see any of the above "special" errors anyway (like ERR_ICAP_FAILURE when the icap service is down), because there seems to be the issue with this error still getting matched by the "http_access deny all" rule with no means to check on the response header... - I always just get to "ERR_ACCESS_DENIED" because of this match.
So unless I remove this final "http_access deny all" rule I always get 403 response - when I remove it I get 500 with ERR_ICAP_FAILURE, but as I do not deny it I cannot apply deny_info.
As I am still in the request phase - I cannot rely on an ACl checking for status 500 or similar (this information is not available yet during http_access) - so I am stuck (actually BEFORE we get to the error page issue that started all this)...
In the end the deny_info only allows me to customize on the deny response, but not on the corresponding errors...
Any ideas?
Okay. A couple of things...
* 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.
* adapted_http_access isused to re-test the request permissions after
ICAP REQMOD and URL-rewrite adaptations have been done on it. Only the
successful requests that pass ICAP should reach here - so catching the
ICAP errors
* http_reply_access is done on all replies right before delivery to the
client. Including ICAP generated ones from both REQMOD and RESPMOD.
* deny_info works in all of the above access lists.
* the error pages %H macro expansion should be usable in some embeded
scriptlet to switch things around depending on the vhost name. While the
template pages have to be static server pages, they can contain
client-side scripts. To the point where the error "page" can be a
javascript stub loading the real error content.
Amos
