Re: [RFC] Configurable SSL error details

[Amos Jeffries]

On Tue, 03 May 2011 10:30:48 -0600, Alex Rousskov wrote:

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.

Yes.

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?

That is pretty much how it has to be done for now.


Amos