<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">W dniu 19.05.2017 o 15:13, Amos
Jeffries pisze:<br>
</div>
<blockquote type="cite"
cite="mid:1d9af110-0fb8-0d12-e340-d9f5503785b5@treenet.co.nz">On
20/05/17 00:44, Dijxie wrote:
<br>
<blockquote type="cite">
<br>
Hi list,
<br>
<br>
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?
<br>
I'm not sure if I get it:
<a class="moz-txt-link-freetext" href="http://www.squid-cache.org/Doc/config/deny_info/">http://www.squid-cache.org/Doc/config/deny_info/</a>
<br>
<br>
</blockquote>
<br>
deny_info is to provide some non-default response payload (aka.
"page") instead of the 403 when an ACL performs administrative
denial of access.
<br>
<br>
As to your purpose; What is this universal message that conveys
all possible environmental conditions to the reader in one simple
text?
<br>
<br>
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).
<br>
<br>
<blockquote type="cite">2. And then, using %e code and presumably
external js nested in this page, display more detailed info for
some error numbers.
<br>
<br>
Can it be done? Can squid internal web server handle easy js?
<br>
<br>
</blockquote>
<br>
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.
<br>
<br>
<br>
If you redirect all errors to one URL any information the client
might have had about the error is destroyed.
<br>
<br>
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.
<br>
<br>
Amos
<br>
<br>
_______________________________________________
<br>
squid-users mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a>
<br>
</blockquote>
<p><font size="-1">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. <br>
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.<br>
Unfortunately, I'm far from VPN right now, so I cannot show you
the sample "unified" error page I've commited till now.<br>
</font></p>
<p><font size="-1">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. <br>
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:<br>
- js nested in squid error page looks for error code<br>
- 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.<br>
- human client has has his explenation like "this is your error,
do not open ticket please, check your URL again" for nxdomain.<br>
</font></p>
<p><font size="-1">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.<br>
I'm not feeling comfortable with this idea, but I also have a
feeling that it might be necessity.<br>
</font></p>
<p><font size="-1">Thank You.<br>
</font></p>
<pre class="moz-signature" cols="72">--
Greets, Dijx.</pre>
</body>
</html>