httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kaspar Brand <httpd-dev.2...@velox.ch>
Subject Re: svn commit: r1054323 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_ssl.xml docs/manual/upgrading.xml modules/ssl/ssl_engine_config.c modules/ssl/ssl_engine_vars.c modules/ssl/ssl_private.h modules/ssl/ssl_util_ssl.c modules/ssl/ssl_util_ss
Date Tue, 04 Jan 2011 06:13:40 GMT
On 03.01.2011 22:11, Stefan Fritsch wrote:
> On Monday 03 January 2011, Kaspar Brand wrote:
>> Ah, right - my mistake. But even on an EBCDIC platform,
>> ap_xlate_proto_from_ascii would only make sense if we were
>> converting pure 8-bit character strings (from ISO-8859-1 to some
>> EBCDC code page), right?
> 
> ap_xlate_proto_from_ascii() does the right thing for DN strings that 
> contain only ASCII characters. For non-ASCII characters it produces 
> broken results, but that would not be a regression. Therefore we 
> should leave the ap_xlate_proto_from_ascii() call there.

Ok, true. For the sake of better "readability", could we put that line
into an #if APR_CHARSET_EBCDIC block, to make it obvious that it's a
no-op for non-EBCDIC platforms?

> Maybe someone
> familiar with EBCDIC can write an improved conversion function (maybe 
> just escape all high-bit characters?).

Does APR-util support some kind of (lossy) conversion from UTF-8 to
EBCDIC? If so, server/util_ebcdic.c could be extended accordingly.

Kaspar

Mime
View raw message