[Web-SIG] HTTP_CONTENT_TYPE and HTTP_CONTENT_LENGTH
manlio_perillo at libero.it
Wed Dec 12 22:18:31 CET 2007
Ian Bicking ha scritto:
>> The gateway is not required to remove HTTP_CONTENT_TYPE and
>> 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
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:
qs = sys.argv
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
More information about the Web-SIG