httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch ...@sfritsch.de>
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 Mon, 03 Jan 2011 21:11:50 GMT
On Monday 03 January 2011, Kaspar Brand wrote:
> On 03.01.2011 19:21, Eric Covener wrote:
> >> on EBCDIC platforms, ap_xlate_proto_from_ascii simply does
> >> nothing (it calls apr_xlate_conv_buffer, which returns
> >> APR_ENOTIMPL, even in current versions of APR-util, IIMN).
> > 
> > For EBCDIC you're being mislead by the !APR_HAS_XLATE half of
> > xlate.c -- it's not a no-op.
> 
> 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. Maybe someone 
familiar with EBCDIC can write an improved conversion function (maybe 
just escape all high-bit characters?). But I don't see that as a 
showstopper.

Mime
View raw message