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

Amos Jeffries 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: 
>>> 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.
>

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 
database API.

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.

Amos



More information about the squid-users mailing list