Re: [PATCH] [RFC] custom error pages

On Sun, 21 Nov 2010 14:50:20 +0100, Henrik Nordström
<henrik_at_henriknordstrom.net> wrote:
> lör 2010-11-20 klockan 18:58 +1300 skrev Amos Jeffries:
>
>> To simplify the error page loading a symlink is added from the
templated
>> /usr/share/squid/errors/local to that /etc/squid/errors.d folder and
>> checked just before loading the errors/templates/ backup.
>
> Why? I find having this symlink confusing, and yet another potential
> source of configuration errors.

Okay. As Robert pointed out the symlink is not going to work everywhere.
If the idea is agreed I'll go back to an older idea of a separate full
lookup path and some further performance optimisations.

As to why. We currently have admin who still:
 a) want to replace the entire template set with something else
 b) want to replace just some of the template set with something else
 c) want to add local deny_info ERR_* pages with alternative names

The error_directory + auto-negotiate currently caters for (a) and (c) but
not (b).

This replaces error_directory with a fixed location which can be used to
override auto-negotiate for cases (a) and (b). And also as a known location
for case (c).

My earlier idea was to let them add to errors/templates/ but some distros
need to remove or replace that folder when upgrading the langpack content.

Placing this under /etc/squid/errors.d keeps everything which is manually
configurable in one area. So the admin no longer even really needs to worry
about /usr/shared/squid/errors/ or what is in there.

>
> Also is errors.d language sensitive?

hmm, interesting. It could be made so. With this update it is not.

> If so, is there a "default"
> language that overrides all languages?

The languages works on a back-oriented model. With the primary source
being preferred, but a series of backups available.

errors.d/ would be that override language on a per-page basis. If anything
by the wanted template name exists there it is used instead of the slow(er)
language lookups.

Currently we have two override sequences:

 if (error_directory)
   error_directory $full-path
 else
   Accept-Language: $which [, $which [...]]
   error_default_language $which
 errors/templates/* (english)

The sequence of overrides would be:
 errors.d/*
 Accept-Language: $which [, $which [...]]
 error_default_language $which
 errors/templates/* (english)

The patch here is missing a few possible performance optimizations.
 The first I intend to get in with a re-submission if this idea is
accepted. That is to add a flag to the template data loaded on
initialization to indicate whether its used unconditionally (override) or
auto-negotiate is to happen first (presently only loaded as the final
templates/* backup). This removes 1-2 cycles of file lookup on each error
request.
 Second was suggested by Adrian way back. To load the entire template set
into a memory tree and search that. This is a bit more work and requires
some performance/cost benefit analysis I don't have time for.
 Third is a smaller alternative to the second, just to cache the languages
which are available. Thus reducing some useless file probes. We have most
of the major web languages and their variants, but there are a few which
still hit two file loads.

Amos
Received on Mon Nov 22 2010 - 00:21:26 MST