Bug #1687

Generate dir listings on GETs only

Added by HenrikHolst over 9 years ago. Updated about 9 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Missing in 1.5.x:


The mod_dirlisting module creates dir listings for all HTTP methods while it really only should do that for GETs.

mod_dirlisting.c.patch (467 Bytes) mod_dirlisting.c.patch patch against mod_dirlisting.c HenrikHolst, 2008-06-11 13:47

Associated revisions

Revision 0c16fddd (diff)
Added by stbuehler about 9 years ago

Handle only HEAD, GET and POST in mod_dirlisting (same as in staticfile) (#1687)

git-svn-id: svn:// 152afb58-edef-0310-8abb-c4023f1b3aa9


#1 Updated by Anonymous over 9 years ago

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.

#2 Updated by HenrikHolst over 9 years ago

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).

#3 Updated by Anonymous over 9 years ago

mod_dirlisting is normally loaded as one of the last modules.

#4 Updated by HenrikHolst over 9 years ago

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?

#5 Updated by Anonymous over 9 years ago

maybe. but shouldnt your patch then return http 405 instead?

#6 Updated by HenrikHolst over 9 years ago

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 :-)

#7 Updated by Anonymous over 9 years ago

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

#8 Updated by HenrikHolst over 9 years ago

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

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

#9 Updated by stbuehler about 9 years ago

  • Status changed from New to Fixed
  • Resolution set to fixed

Fixed in r2253, r2254 to do the same as mod_staticfile: accept GET, HEAD and POST

Also available in: Atom