Package: media-types Version: 3.0.0 Severity: normal Recent versions of media-types (1.1.0 and 2.0.0) have introduced some lines with extension appearing in both lowercase and uppercase form:
audio/AMR amr AMR audio/AMR-WB awb AWB audio/EVRC-QCP qcp QCP image/t38 t38 T38 image/vnd.globalgraphics.pgb PGB pgb However most tools that lookup the mime.types database will already lowercase the extensions before doing so. After all we are used to have PICTURE.JPG recognized as image/jpeg even if JPG is not listed in mime.types. For instance the Perl script "see", distributed by the mailcap package will lowercase all extensions when mime.types is read, and will lowercase any extension before looking it up. Python's mimetypes.guess_type() function will lookup the extension unmodified first, and then the lowercase version if the first lookup failed. For this implementation it means that mime.types could force some extensions to have some upper case letters. Some tools will complain if some entries in mime.types have duplicate extensions (in some case-insensitive sense). For instance the above lines are causing Bug#979232 for lighttpd. So the question is what is the intended semantics for the above lines? Is "audio/AMR amr AMR" really meant to achieve more than "audio/AMR amr"? Also note that mime.types lists some extensions with only uppercase versions, or a mix of lower and upper case letters: application/vnd.sar SAR application/vnd.ves.encrypted VES application/x-font-pcf pcf pcf.Z Those entries will behave differently for "see" and Python's "mimetypes.guess_type()". For instance "see" will consider "foo.sar" as application/vnd.sar, but "mimetypes.guess_type()" will not. It would be nice to clarify the semantics in the comments at the top of mime.types. -- Alexandre Duret-Lutz
