Ian Bicking ha scritto: > [...] >> >> The gateway is not required to remove HTTP_CONTENT_TYPE and >> HTTP_CONTENT_LENGTH; >> at least this is what CGI says (and WSGI says nothing about this). >> >> In fact in mod_wsgi for Nginx I don't remove these two variables, >> since it requires extra code (but I will remove them, if there is a >> good reason for doing so). > > I never really read through the spec for this, but by convention all > servers I know of do remove these. Having the same header show up in > multiple places seems dangerous (where the two values may not match, > especially if the request has one of those keys rewritten).
Well, with mod_wsgi for nginx an user *can* rewrite *every* variable passed to the WSGI environment (with the exception of the variables in the wsgi namespace, SCRIPT_NAME and PATH_INFO) using the `wsgi_var` directive (to be precise in the current version the user can not override HTTP_ variables since the `wsgi_var` variables are inserted in the enviroment dictionary before the HTTP_ variables, but I'm going to change this right now). WSGI variables are all added using the `wsgi_var` directive. > 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. 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. Thanks Manlio Perillo _______________________________________________ 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
