[Web-SIG] HTTP_CONTENT_TYPE and HTTP_CONTENT_LENGTH

[Ian Bicking]

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 : ianb at colorstudy.com : http://blog.ianbicking.org