* Łukasz Mierzwa <[email protected]> [2013-03-08 21:37]: > [-- Attachment #1 --] > [-- Type: multipart/alternative, Encoding: 7bit, Size: 3.2K --] > > 2013/3/8 Guido Berhoerster > <[email protected]> > >> Removing the check indeed fixes the problem. This breaks >> quite a few CGI and PHP scripts which expect that POSTing to >> itself works when served as an index document. > > > We have 2 things here: > 1) with static files served by uWSGI itself (using --check-static and > related options) AFAIK it makes little to no sense to return static file as > a response to requests other than GET and HEAD (this is what my pull > request was about)
Agreed, that limitation maskes sense for static files. > 2) next I'm not sure: > a) cgi (and possibly other plugins) are using static files serving features > to work and require to handle all methods during that (?) > b) cgi requires some code to be executed in protocol.c that is never > executed since the check above prevents that from happening (?) > > If most plugins do need this check and only few do, than maybe each plugin > could define set of methods it handle and we would than check in protocol.c > if the method user requested will be handled by the plugin itself, if not > we handle it there (?) But I'm not sure if it does even makes sense, it > might be my evening mumbling. > > Anyway removing check completely will break some apps, so we need to make > it smarter. Hmm, I don't see how such a whitelist of HTTP methods a plugin handles could possibly work, e.g. how should the cgi or php plugin decide which methods the script it executes handles? And there are use cases like scripts that implement a complete WebDAV server. So I think the check should be made for static files but in other cases plugins need to be passed requests without restricting methods. -- Guido Berhoerster _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
