[squid-users] How to redirect all squid's error pages to one?

Dijxie dijxie at gmail.com
Fri May 19 14:55:11 UTC 2017

W dniu 19.05.2017 o 15:13, Amos Jeffries pisze:
> On 20/05/17 00:44, Dijxie wrote:
>> Hi list,
>> 1. I'd like to redirect **all** squid error pages to one, universal, 
>> preferably internal squid error page. For sure I can symlink every 
>> error page to one, but is there a clener way?
>> I'm not sure if I get it: 
>> http://www.squid-cache.org/Doc/config/deny_info/
> deny_info is to provide some non-default response payload (aka. 
> "page") instead of the 403 when an ACL performs administrative denial 
> of access.
> As to your purpose; What is this universal message that conveys all 
> possible environmental conditions to the reader in one simple text?
> Keep in mind that the reader may not be human; some errors are 
> explanations of indirect problems and only visible when the 
> accompanying machine instructions reach a failure (eg 30x, 401, 407 
> messages); and some are not errors at all but instructions for a user 
> on what they need to do to continue with communication (eg 511 login 
> pages).
>> 2. And then, using %e code and presumably external js nested in this 
>> page, display more detailed info for some error numbers.
>> Can it be done? Can squid internal web server handle easy js?
> Squid is not a web server. On "error" it produces message payloads 
> which happen to contain HTML by default. Modern HTML can contain 
> embedded scripts, but they are not interpreted by Squid as anything 
> beyond opaque characters.
> If you redirect all errors to one URL any information the client might 
> have had about the error is destroyed.
> The symlinking you though of is the "best" way to do what you are 
> asking for. However, think carefully about what the purpose of 
> displaying an error message is, see above.
> Amos
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

The purpose is to provide unified, debug info for 1st line of support. 
End users in my corpo are not best IT trained people in the world and 
they tend to open tickets for any reason, usually pasting printscreen 
into ticket.
Simple debug info like: IP, user name, client name, cache name in short 
list would help service desk to divide "moronic" tickets from important 
ones, and as for default squid info pages... user do not read them 
anyway. I do not want to remove error codes, I just want to remove 
content of most error pages and replace it with unified message that 
also contains raw error code (%e, %E) and add some more information if 
%e will be nxdomain or access denied for example.
Unfortunately, I'm far from VPN right now, so I cannot show you the 
sample "unified" error page I've commited till now.

But indeed, you have striked the home; cache users are both human and 
machine$ AD accounts, I must reconsider that. Perhaps parsing all error 
pages with sed ie and adding few lines will be easer and more 
convenient, anyway.
I know that squid is not web serwer, but error page is html; I assume it 
can contains iframe served from external web server and this will be 
rendered by client's browser, not squid? My idea was:
- js nested in squid error page looks for error code
- then redirects nested iframe to specific URL hosted on external httpd 
depending on error code. If error code is unimportant for human (user 
can do nothing with that anyway), iframe stays blank.
- human client has has his explenation like "this is your error, do not 
open ticket please, check your URL again" for nxdomain.

We are talking about ~2K users and 3-4 cache servers. I must take 
comfort of first line support into concideration, they are quite 
heavy-loaded already.
I'm not feeling comfortable with this idea, but I also have a feeling 
that it might be necessity.

Thank You.

Greets, Dijx.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20170519/5958ef87/attachment-0001.html>

More information about the squid-users mailing list