Re: [RFC] Configurable SSL error details

On 05/02/2011 06:15 PM, Amos Jeffries wrote:
> On Mon, 02 May 2011 12:51:21 -0600, Alex Rousskov wrote:
>> Hello,
>>
>> Currently, the contents of %D error page code expansion is
>> hard-coded:
>>
>>> static SslErrorDetailEntry TheSslDetailArray[] = {
>>> {X509_V_ERR_UNABLE_TO_GET_CRL,
>>> "X509_V_ERR_UNABLE_TO_GET_CRL",
>>> "%err_name: %ssl_error_descr: %ssl_subject",
>>> "Unable to get certificate CRL"},
>>> {X509_V_ERR_UNABLE_TO_DECRYPT_CERT_SIGNATURE,
>>> "X509_V_ERR_UNABLE_TO_DECRYPT_CERT_SIGNATURE",
>>> "%err_name: %ssl_error_descr: %ssl_subject",
>>> "Unable to decrypt certificate's signature"},
>>> {X509_V_ERR_UNABLE_TO_DECRYPT_CRL_SIGNATURE,
>>> "X509_V_ERR_UNABLE_TO_DECRYPT_CRL_SIGNATURE",
>>> "%err_name: %ssl_error_descr: %ssl_subject",
>>> "Unable to decrypt CRL's signature"},
>> ...
>>
>>
>> Hard-coded text prevents folks from fully translating and customizing
>> error pages containing %D codes.
>>
>> I suggest that we add support for a translatable and customizable error
>> detail file. The file may be stored like we store error page templates
>> today. Inside the file, we can use HTTP-like format that can be later
>> extended to other error details (and beyond):
>>
>> key1: value
>> key2: value
>> key3: value
>>
>> key1: value
>> key2: multi
>> line
>> value
>> key3: "value with meaningless quotes that will be stripped"
>> key4: "value with a \"quoted string\" inside"
>> ...
>>
>> We can use HTTP header parser to parse the above, I guess. If the above
>> is too fragile, we can wrap each group of key/value pairs:
>>
>> {
>> key: value
>> key: value
>> key: value
>> }
>>
>> or use some other format that we can already parse. The important things
>> here are:
>>
>> - support groupings of key/value pairs (because one error code is
>> often associated with multiple strings/details)
>>
>> - support long text, markup, and translations (because that is what
>> error pages and other contexts may need)
>>
>> - reuse existing parsing code to the extent possible
>>
>>
>>
>> For example, for the first two SSL error details quoted above, the two
>> error-details.txt file entries may look like this:
>>
>> name: X509_V_ERR_UNABLE_TO_GET_CRL
>> detail: "%err_name: %ssl_error_descr: %ssl_subject"
>> descr: "Unable to get certificate CRL"
>>
>> name: X509_V_ERR_UNABLE_TO_DECRYPT_CERT_SIGNATURE
>> detail: "%err_name: %ssl_error_descr: %ssl_subject"
>> descr: "Unable to decrypt certificate's signature"
>>
>>
>> I am not a translation expert. Is there a better way to make error
>> details configurable and translatable while still grouping related
>> details together? Any other suggestions before we start implementing the
>> above?

> .PO is the basic standard for translation and integrates well.

After looking at gettext/PO documentation, I am tempted to conclude that
we should not try to mix translation and configuration. That is, we
should have one configuration file and then use .po file(s) to translate
strings in that configuration file as needed.

This would be similar to translating an error page template into various
languages: the template is the configuration file and the rest is
translation-specific stuff that does not really care about the
configuration file format and such.

If Squid migrates from .PO to some other, better translation mechanism,
the error detail translation will be migrated as well. We are not trying
to improve the translation mechanism here, just make existing error
detail strings translatable using whatever mechanism Squid already supports.

Would you recommend a different approach?

Even if this separate-configuration-from-translation approach is
accepted, we still need a configuration file format. The proposed
key:value format can still be used, I think. Any better ideas?

Thank you,

Alex.

> It can be built into a binary .MO format for loading by Squid
> (http://www.gnu.org/software/hello/manual/gettext/MO-Files.html). XLIFF
> is a newer alternative of the human editable format with more meta data
> we might want to use, but there are fewer tools to work with it.

> The blocker problem is that the gettext() API used almost universally
> for translation works on assumption that output is for the global system
> environment. We need a re-implementation of gettext() so that we can
> pass it the string key and an HTTP compatible language code on demand
> instead of setting the environment LANG() several times to use the
> default gettext().
>
> The simple but terribly slow and nasty re-implementation would be
> something like:
>
> const char *
> xgettext(key, lang)
> {
> const char *result;
> // lookup current environment language -> save
> // set $lang as environment language (converting from HTTP standard
> format to GNU ENV format)
> result = gettext(key);
> // restore environment language
> return result;
> }
>
>
> Amos
Received on Tue May 03 2011 - 16:31:25 MDT