|Summary:||mod_mime_magic generates incorrect response header|
|Product:||Apache httpd-2||Reporter:||ABE Hiroshi <hiro-abe>|
|Component:||mod_mime_magic||Assignee:||Apache HTTPD Bugs Mailing List <bugs>|
|Attachments:||patch to show the mod_mime_magic.c has a bug|
Description ABE Hiroshi 2003-02-27 16:18:21 UTC
Apache-2.0.44 with mod_mime_magic generates incorrect responses for some files in Japanese. The problem seems to happen when the requested file includes escape character (Japanese files encoded in ISO-2022-JP always include it) and does not have any extensions. The following procedure reproduces this problem: 1. generate a file with escape character: % perl -e 'print "Nagoya, the 3rd largest city in Japan, is written as \x1b\$BL>8E20\x1b(B in Japanese."' > file_with_escapes, 2. copy it to somewhere accessible via Apache 3. and request it through Apache with mod_mime_magic. When I tried the procedure above, I got --- snip ---- HTTP/1.1 200 OK Date: Apache/2.0.44 (Unix) DAV/2 Last-Modified: Sun, 16 Feb 2003 15:05:28 GMT ETag: "92611-4e-319e00" Accept-Ranges: bytes Content-Length: 78 Connection: close Content-Type: text/plain ; charset=ISO-8859-1 Content-Encoding: (with --- snip --- as HTTP response. I think the value of Content-Encoding header is wrong. Regards, ABE Hiroshi
Comment 1 André Malo 2003-03-05 19:32:26 UTC
mod_mime_magic does more or less black magic, which is known not to work always as desired ;-) Sorry, it's the nature of mod_mime_magic to _guess_ the file type. So if the guess is wrong, you have to change the magic file or, even better, configure the filetype explicitely. So it's all in all a configuration problem, not a bug. Thanks for using Apache.
Comment 2 ABE Hiroshi 2003-03-06 03:57:22 UTC
Created attachment 5175 [details] patch to show the mod_mime_magic.c has a bug
Comment 3 ABE Hiroshi 2003-03-06 04:19:43 UTC
I understand there are some case the mod_mime_magic does not work as I want to. But still, I think there is a bug in mod_mime_magic because I think the Content-Encoding header may not have `` (with'' as its value in this case. To show this is bug, I tried the procedure in the first report with attached patch. Then I got ---- snip ---- HTTP/1.1 200 OK Date: Thu, 06 Mar 2003 03:36:07 GMT Server: Apache/2.0.44 (Unix) DAV/2 Last-Modified: Thu, 27 Feb 2003 16:15:04 GMT ETag: "8f8ba-4e-415b7200" Accept-Ranges: bytes Content-Length: 78 Connection: close Content-Type: text/plain_(with_escape_sequences); charset=ISO-8859-1 ---- snip ---- The value of ``Content-Type'' header is slightly changed and there is no ``Content-Encoding'' header. In my opinion, whitespaces in the header causes this.