Lighttpd

i really dont see a reason why we shouldnt do that for other request types too.
can you give some reasons? what should we return for POST e.g.?

HEAD e.g. should do the same as GET and just leave out the body in the response.
so your patch would be wrong already.

I agree that HEAD should be checked as well, but I cannot understand why you would like POST, PUT, DELETE, COPY, MOVE etc to generate a dir listing?

Granted that this would only occur on misconfigured servers, but atleast I find it really strange to get a dir listing back instead of say a "501 Not Implemented" on say a DELETE.

The thing is that mod_dirlisting catches all requests before say mod_fastcgi which is where we detected this (a COPY request for a directory that we tried to write a FastCGI application for got stuck in mod_dirlisting). Now this might be due to a misconfiguration on our part (but the load order of mod_dirlisting seams hardcoded).

mod_dirlisting is normally loaded as one of the last modules.

Hmm, it might be that our FastCGI application is not doing everything correctly since it seams like mod_dirlisting is catching the reuqest after mod_fastcgi and not before as I first thought,

Anyways don't you see it as semantically wrong to return a dirlisting on a DELETE or POST?

maybe. but shouldnt your patch then return http 405 instead?
http://rfc.net/rfc2616.html#s10.4.6

Well mod_dirlisting would be a very strange place to do this in since it wouldn't be what one expected to find inside one of the plugins. mod_dirlisting provides dir listings but seams to also perform some sort of catch-all functionality?

A 405 should be returned by the lighttpd core if none of the modules catched the request (and the request was not a GET or HEAD), which would also be difficult since we would have to filter out situations where no module catches the request due to a possible 404. Something that probably then instead should be set during compile time (that is every module have to register which methods they support and the HTTP_METHOD_ enum would this be built from this register, and any request to any other method would yield a 405), not fun for externally build modules though...

Hmm this was difficult :-)

imho ... given mod_dirlisting runs almost as last module in the chain you can easily return 405 there.

Well yes, but that feals like to Quick-N-Dirty a fix somehow :-)

I think I better let it rest a while...