On 12/05/16 15:50, Roberto De Ioris wrote:
On Tue, May 10, 2016 at 10:44:27AM +0200, Roberto De Ioris wrote:
I'm trying to set up uwsgi with cgi plugin and git-http-backend, to
see if we get better performance with uwsgi over fastcgi (http-git
performance is fairly important to us for git.kernel.org).
However, all my attempts have been in vain thus far, because
attempting
to clone always hangs -- GETs work just fine, but when we try to do a
POST, git-http-backend enters endless read() and then things time out.
Apparently, this is because STDIN with POST data is never closed.
Hi again, this patch should address it:
https://github.com/unbit/uwsgi/commit/ac1e354fcf16583a5b242bb0ed36fa5e3be41701
(just add cgi-close-stdin-on-eof = true to the options)
Thanks, Roberto, I'll check it out. Shouldn't this be true by default,
since otherwise CGI POST doesn't work at all?
Hi, our first rule is "never change behaviours before a looong deprecation
phase". uWSGI cgi plugin is one of the most used one, so it is a risk to
change an established behaviours (stdin like in a WSGI/PSGI/Rack app).
In 2.1 we can absolutely think about setting it as the default
Besides which... it's not been a problem until now....
To refresh my memory, I hunted down the CGI spec I used to need so
regularly.... and found this:
http://web.archive.org/web/20100212094332/http://hoohoo.ncsa.illinois.edu/cgi/in.html
"""
The server will send CONTENT_LENGTH bytes on this file descriptor.
Remember that it will give the CONTENT_TYPE of the data as well. The
server is in no way obligated to send end-of-file after the script reads
CONTENT_LENGTH bytes.
"""
So I'm curious why you expect stdin to be closed?
--
Curtis
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
