Manlio Perillo wrote: >> And of course it's not much code to remove them. There's some things >> that technically are okay with WSGI, but in practice are bad (like >> leaving out QUERY_STRING, which can cause very weird bugs due to how >> the cgi module was written). >> > > QUERY_STRING can be a problem for me, since I don't add to the > environment dictionary empty variables, with the exception of > SCRIPT_NAME and PATH_INFO. > > Well, not a real problem, since it easy to make sure that it is always > present in the WSGI environment dictionary. > > By the way: the CGI spec > (http://cgi-spec.golux.com/draft-coar-cgi-v11-03-clean.html) > requires QUERY_STRING to be *alway* present, but the WSGI spec allows it > to be absent.
Yes, there's a couple keys like that, I'm afraid; SCRIPT_NAME and PATH_INFO too, I think. > P.S.: I'm reading the cgi module and it only uses argv[1]: > if sys.argv[1:]: > qs = sys.argv[1] > > I'm not sure to understand. > > Moreover in mod_wsgi for nginx, I call PySys_SetArgv, so the WSGI > application sees the command line options passed to nginx. I don't know *why* cgi does this, but as you can imagine it's weird and unhelpful when it does. Having QUERY_STRING set avoids this problem. Most framework do (or should) make sure it's set before calling the cgi module, but someone who uses it directly could get a weird error as a result. I don't think there's anything wrong with exposing sys.argv; what the cgi module does is just weird. -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
