Generate dir listings on GETs only
|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.
#1 Updated by Anonymous about 6 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 about 6 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).
#4 Updated by HenrikHolst about 6 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?
#6 Updated by HenrikHolst about 6 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 :-)
Also available in: Atom