Re: [RFC] Configurable SSL error details

 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
Received on Tue May 03 2011 - 22:35:51 MDT