> 1. > This is the general setup i have at the moment: > http://dpaste.com/hold/362090/ > plain/ > > basically nginx frontend dynamically invoking uWSGI based on provided > SCRIPT_NAME and host, and uWSGI handles python scripts. > > for GET everything works as expected, however for POST request there are > certain anomalities: > > $ curl -d "" http://pkolla:88/report/ > p report > $ curl -d "anything" http://pkolla:88/report/ > $ > > if anything is passed as post-data the serverside does not return anything > to > client (local, remote, wget, browser or curl - no difference) > > more details available here: http://dpaste.com/362107/plain/ > > the issues seems to be somewhere on way back from uWSGI to nginx, > nginx claims that conneciton was dropped but based on packet sniffing with > tcpdump/tshark i can see that uWSGI seems to work very similar in both > cases, > with or without post-data > > detailed traffic dumps no post data: http://dpaste.com/362049/plain/ > and with post data: http://dpaste.com/362051/plain/
This is a long-talked-about-but-without-a-common-agreement discussion done on this list and in the web-sig (and on nginx list but related to php). Is the app "forced" to read the wsgi.input content ? You are seeing this behaviour because uWSGI close the connection when there are still data in the socket. This happens on other non-uwsgi related upstream server and Maxim from nginx already fixed nginx to allow this, but its patch did not get in the official releases. To solve it simply read the wsgi.input (if content_length > 0) or add --post-buffering <n> to your command line. (side note: you are running uWSGI with only 1 worker, it could be not enough for a fast server like nginx if you plan to deploy more complex apps) > > > 2. Probably irrelevant to first issue but just in case: despite launching > uWSGI > with --no-default-app param i still see in logs: > > setting default application to 0 this should be changed for sure, it get printed independently from no-default-app > > And in case if uWSGI gets request which is not possible to handle because > of > missing modules (due to domain and hence document root & python path not > physically existing), the request is being passed to whichever app was > handling > same module (looks like script_name seems to matter here) on some other > domain. > Yet in case if there were no default application set - it returns an error > as > expected. > > Will appreciate any help, thanks in advance no-default-app will came in when you ask for non-configured SCRIPT_NAME, so if you have configured in uWSGI /foo /bar and ask for /ops The last one will be mapped to /foo (if you pass --no-default-app you will receive an error) If /foo or /bar have errors they will spit-out errors. If it does not work in this way this is a bug for sure. -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
