Re: [RFC] Configurable SSL error details

 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. 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 - 00:15:37 MDT