Feature #2942


incorrect behaviour of

Added by geusebi almost 5 years ago. Updated almost 5 years ago.

Target version:


Some of what I'm going to report might be intended behaviour. If it is so, skip that part.

/usr/share/lighttpd/ incorrectly parse /etc/mime.types :

  1. mimetype could contain a comma,
  2. uppercase characters makes an entire rule to fail,
  3. lines which ends with a slash aren't joined to following lines,
  4. some special character is not recognized.

The attached file is python code which replace solving the first 3 problems.

The first point is probably due to a wrong ordering in the first character class on line 10
( i.e. it should end with ".+-]" instead of "+-.]" ).

The second point cause every rule containing an uppercase character to fail.
A rule like:

application/x-font-pcf                pcf pcf.Z

disappear entirely instead of generating the rules:

".pcf" => "application/x-font-pcf",
".pcf.Z" => "application/x-font-pcf",

The third point is probably intended behaviour, but since it might generate bad rules, it should be handled correctly.

Fourth point is only for this rule (on my machine):

application/x-trash                             ~ % bak old sik

but I think it might be safely ignored.

Thanks in advance,

Files (769 Bytes) Alternative implementation of in python geusebi, 2019-03-14 02:15 (845 Bytes) Alternative implementation of in python geusebi, 2019-03-14 02:36
Actions #1

Updated by geusebi almost 5 years ago

Updated the python version to exit immediately when mime.types is not readable.

Actions #2

Updated by gstrauss almost 5 years ago

  • Tracker changed from Bug to Feature
  • Status changed from New to Invalid

1. mimetype could contain a comma,

How is this a "problem"? The character class containing [+-.] is not what was intended, but happens to contain '+' ',' '-' '.' so actually matches all intended characters plus ',' That a mime type could contain a comma and still be parsed should not cause any problems. After all, that would need to be present in /etc/mime.types.

2. uppercase characters makes an entire rule to fail,

Did you test that? The regex ends in /i so it is a case-insensitive match.

3. lines which ends with a slash aren't joined to following lines,

Is there a distro which does this that you could point to as an example? This would be a limitation, not a bug.

4. some special character is not recognized.

This is also a limitation, not a bug. Is there a distro that ships with mime.types containing special characters, or is that something you added? You can configure any valid extension chars in mimetype.assign if you list them explicitly.


Is there a reason that you posted python code which does not reimplement all the features of the existing script?

Actions #3

Updated by geusebi almost 5 years ago

Sorry to have wasted your time, it wasn't my intention.
You are right.

I've installed lighttpd (version 1.4.45) with apt in a clean Debian 9.6.

And this is the file I found installed (see at end of this post).
I, wrongly, assumed it was coming from the official lighttpd repository. It's my fault.
The reason of the python script was that I noticed that some extensions where missing (the ones with uppercase characters). So, I tried to reimplement it in python while reading the perl code below and also "man mime.types". Which I now realize was from CUPS, a more complex file format which I should have ignored (again, sorry).

For point number 4: apparently, the very debian version on which I installed lighttpd ships:

user:~# cat /etc/mime.types | grep x-trash
application/x-trash                ~ % bak old sik

Here you can see the special characters. And you're right I can add them explicitly.

Point number 3: (backslash) was mentioned in the manual of 'mime.types' (to be ignored since it's from CUPS):

       Rules can be extended over multiple lines using the backslash character
           mime/type [ really-really-really-long-rule ... \
             rule ]

File '' on Debian 9.6 lighttpd 1.4.45.

user:~# cat /usr/share/lighttpd/ 
#!/usr/bin/perl -w
use strict;
open MIMETYPES, "/etc/mime.types" or exit;
print "mimetype.assign = (\n";
my %extensions;
while(<MIMETYPES>) {
  next if /^\w*$/;
  if(/^([a-z0-9\/+-.]+)\s+((?:[a-z0-9.+-]+[ ]?)+)$/) {
    foreach(split / /, $2) {
      # mime.types can have same extension for different
      # mime types
      next if $extensions{$_};
      $extensions{$_} = 1;
      print "\".$_\" => \"$1\",\n";
print ")\n";

Thanks again,

Actions #4

Updated by gstrauss almost 5 years ago

There have been over 625 commits to lighttpd source code between the release of lighttpd 1.4.45 and up through lighttpd 1.4.53. The Debian Stretch package of lighttpd is woefully out of date, and that is unfortunately a problem in Debian, not in lighttpd. The Debian lighttpd package maintainers went AWOL. It took some effort to get other Debian developers to mark the package as orphaned in Debian.

Recently, Helmut Grohne put in quite a bit of effort getting the lighttpd Debian package back into shape for Debian Buster.

In Debian Buster, Debian uses the from the lighttpd repository. This was committed 3 months ago
and fixed Debian bug

The long and short is this: in order not to waste your time (or mine), if you report bugs on the official lighttpd site, please check that the bug still exists in the latest official version of lighttpd. If a bug is specific to your distro of choice, then please check the distro to see if the package management has addressed the issue, or if the issue is with the distro package management rather than in the official lighttpd release.

You can hopefully see that we try look into and respond to bug reports reasonably quickly. However, nobody likes to waste time on things that have been fixed months or years ago. Users don't like to repeatedly trip over things that have been fixed long ago, and developers don't like to re-troubleshoot things that have been fixed long ago. This problem can be avoided with good package maintainers in each widely used distro.

Please consider filing feature requests for enhancements, not bug reports. If you are not sure if something is a bug or a feature, you should probably err on the side of making a feature request. I don't think that supporting application/x-trash is a bug. First, is an optional helper script. Second, application/x-trash, as you might imagine, is not an official IANA-registered MIME type.

Actions #5

Updated by geusebi almost 5 years ago

I'll keep everything you said in mind the next time I'll file a bug report here or elsewhere.

I must say that you've been very quick and clear in your response.
Thank you for your answers and many thanks to all the team for lighttpd. I just started using it and it looks like a great web server.



Also available in: Atom