> Thanks a lot Roberto, this is exactly what I'm looking for. > > Just out of curiosity, if the body has to be read anyway, why not read > it in uWSGI by default? > And then the application can choose to use the body or not, but no > error will be reported even > if the application forget to read the body (or sometimes for certain > request the application just > don't care the "body"). > > I had this issue when I was trying to do some "insane" operations, > which is to give a "body" to > a "GET" request. This will not happen in a sane application such as a > web browser, but it could > happen in an HTTP programming library, where you never know what kind > of "insane" operations > the client could ever make, and in all my request handler, I have to > read body the very first thing > to do. Is it because of performance considerations or something else? >
The main thing is that uWSGI core should be less invasive as possible to support different technologies/languages. Things like php and the Rack standard expect the body to be always read by specs, while WSGI and PSGI (for example) do not have such assumption. What you are facing is a "low-level thing", so basically whatever choice you made you break something else. Non-buffering advantages: supports websockets upload progress do not use memory or disk space leave control to the user about the body you can manage huge amount of uploads with async/evented engines (this could work one day even in buffered mode) Non-buffering disadvantages: you can easily clobber the communication with the web proxy, and each webproxy react differently (nginx explodes, apache and the uwsgi http router have no problems as well as cherokee and so on...) So there is no specific or winning reason to have non-buffering by default, it loooked sane when there was only apache and cherokee and changing defaults in a project like uWSGI (with paying customer) is always a bad thing ;) The funny thing is that if you do not like a default of uWSGI you can write your alternative ini config file that can be embedded in the binary, so you will not need anymore to bother about that. -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
