Re: [RFC] Configurable SSL error details

Mon, 02 May 2011 17:15:39 -0700 

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

Reply via email to