On Thu, May 12, 2016 at 03:59:13PM +1000, Curtis Maloney wrote: > > > 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?
Well, I don't really expect anything -- I was trying to get a very common CGI to work with uwsgi, and it wasn't working at all. I don't know enough about CGI specs to debate the "right way" to do it, just pointing out that trying to run the same sample CGI under Apache (which I would call "reference CGI implementation," honestly) and uwsgi resulted in a different behaviour on POST. Apache always appears to close stdin after it is done writing POST, and my guess is that many apps expect that behaviour and don't bother paying attention to CONTENT_LENGTH. Regards, -- Konstantin Ryabitsev Linux Foundation Collab Projects Montréal, Québec
signature.asc
Description: PGP signature
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
