httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <>
Subject Re: Why can't ap_send_error_response() count on charset?
Date Tue, 13 Aug 2002 15:06:57 GMT
Carlo Perassi wrote:
> Hi all.
> In modules/http/http_protocol.c
> the comment say
> ap_send_error_response is used for any response that can be generated by the
> server from the request record. This includes all [snip] messages that have
> not been redirected to another handler via the ErrorDocument feature.
> On line 2331 I read:
> /* can't count on a charset filter being in place here,
>  * so do ebcdic->ascii translation explicitly (if needed)
>  */

This code produces worst-case error messages.  We can't assume that
mod_charset_lite's output filter (or any other resource filter) is present and
working, because there are many reasons why it might be missing or
non-functional, including user configuration errors.  So on ebcdic platforms, we
must explictly translate the error messages from the native charset used in the
source code to ascii.  In non-error situations, ebcdic->ascii charset
translations (and vice versa) are done using filters.

> Anyway... with the actual code, the html generated by ap_send_error_response
> can't pass the W3C Validator test (with the missing meta line it would be ok).

I just committed a fix a few minutes ago which should fix http header problems
with the worst case error messages, as well as the ebcdic issue.  With this fix,
ap_send_error_message should *always* send a good http Content-Type header
containing the values set up on line 2264:

ap_set_content_type(r, "text/html; charset=iso-8859-1");

Can you try it again with current cvs HEAD?  I'm not familiar with the W3C
Validator test, but I would hope that if it saw a good http Content-Type header,
it wouldn't need the stuff in the html meta line.


View raw message