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. Greg
