[squid-users] How to redirect all squid's error pages to one?
squid3 at treenet.co.nz
Fri May 19 15:16:15 UTC 2017
On 20/05/17 02:55, Dijxie wrote:
> 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:
>> 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
>>> 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.
>> squid-users mailing list
>> squid-users at lists.squid-cache.org
> 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.
I think a better approach may be a link they can click on that
automatically reports the details for them. Some of our errors already
include a mailto web link to contact the administrator that embeds the
error details in subject etc as an example. But you can go a bit further
with a jQuery script that pulls IP etc and POSTs them to a support
You can also reduce a bit of the work editing files by pointing
error_directory in squid.conf to a directory with your altered
templates. That will save your changes from being overwritten when the
OS packaged ones update.
More information about the squid-users