On Thu, May 15, 2008 at 01:54:35PM -0400, David Jones wrote: > The response to TRACE when "TraceEnable Off" is not used on an EBCDIC > platform is partially in ASCII and partially in EBCDIC (part readable, part > garbage).
In the 2.2.8 version I recently ported to a /390 machine, this error does not occur. Can it be that mod_charset_lite was not included? It appears as if you have a 2.2.7 apache. Did you try again with 2.2.8? What TRACE command did you send? I tried this: (where the 1st host is a /390 proxy, and the others are ASCII based test proxies): --snip-- % telnet d016ze04.mch.fsc.net 8000 Trying 172.25.81.13... Connected to d016ze04.mch.fsc.net. Escape character is '^]'. TRACE http://www.apache.org/ HTTP/1.1 Host: www.apache.org HTTP/1.1 200 OK Date: Tue, 27 May 2008 12:43:20 GMT Server: Apache/2.2.8 (Unix) Content-Type: message/http Via: 1.1 MHPAKAJC (NetCache NetApp/6.0.6), 1.1 pgtm0035.mch.fsc.net:82 (Apache/1.3.37) X-Cache: MISS from pgtm0035.mch.fsc.net Via: 1.1 deejai2.mch.fsc.net (Apache/2.2.9-dev) Via: 1.1 D016ZE04.mch.fsc.net (Apache/2.2.8) Transfer-Encoding: chunked f3 TRACE / HTTP/1.1 Host: www.apache.org Connection: keep-alive Via: 1.1 D016ZE04.mch.fsc.net (Apache/2.2.8), 1.1 deejai2.mch.fsc.net (Apache/2.2.9-dev), 1.1 pgtm0035.mch.fsc.net:82 (Apache/1.3.37), 1.1 MHPAKAJC (NetCache NetApp/6.0.6) 0 --snip-- One thing however that certainly differs between your apache and mine is the fact that I added a flag to request_rec that gets set whenever the server internally generates stuff. Mod_charset_lite then enforces a EBCDIC-NATIVE-to-ASCII conversion. Its definition looks similar to this: --- httpd-2.2.8.orig/include/httpd.h Thu Nov 15 23:08:30 2007 +++ httpd-2.2.8/include/httpd.h Thu Jan 10 18:53:54 2008 @@ -1002,6 +1002,20 @@ struct request_rec { * record to improve 64bit alignment the next time we need to break * binary compatibility for some other reason. */ +#if APR_CHARSET_EBCDIC + /* + * Flag to indicate forced vs. automatic conversion of the + * response from the charset of the source code to ASCII. + * Set when the response body is coded in the + * implementation character set (i.e., the charset of the source + * code). This would get several different types of documents + * translated properly: mod_autoindex output, mod_status output, + * mod_info output, hard-coded error documents, etc. + * Used by mod_charset_lite to determine whether implicit + * conversions should be applied. + */ + int response_uses_implementation_charset; +#endif }; This flag gets set in: * mod_dav's dav_error_response(), dav_method_options() etc., * mod_example's x_handler(), * mod_autoindex's index_directory(), * mod_status's status_handler(), * mod_proxy_balancer.c balancer_handler(), and I had to rewrite mod_charset_lite somewhat to "do the right thing" with this flag (and with PUT/POST handling in general: the current mod_charset_lite does not properly convert uploaded entities according to their MIME type, it was designed mainly for download conversion). I intend to publish the patch for 2.3.x (and propose a backport for 2.2.x); if you are interested just let me know, so that I can separate it from my other changes made for my employer's 2.2.8 version. Your patch is IMO no longer needed when these changes are applied. HTH, Martin -- <[EMAIL PROTECTED]> | Fujitsu Siemens http://www.fujitsu-siemens.com/imprint.html | 81730 Munich, Germany
