query string parsing problem

[Eric Moritz]

If you use Django with a python version older than 2.4, the cgi.parse_qsl function incorrectly parses query strings. If a query string consists of "?print" the variable is ignored. I fixed this by yanking the pares_qsl function out of a 2.4 version of the cgi module and putting it in django/utils/future_cgi.py and use it instead of the parse_qsl function provided by python. This is only evident when Django is not used with mod_python.

If we want Django to work properly with python 2.3 we may want to include this work around.

[Adrian Holovaty]

Hey Eric, could you provide the patch?

[Malcolm Tredinnick]

This is a real bug (in Python 2.3). We should be using our own version of parse_qs for 2.3, as Eric suggests. The specific thing about the query string he mentions is that it's not of the form "?name=value", it's just "?name", which is still valid.

[arien <regexbot@…>]

The attached patch makes it so that parse_qs, parse_qsl, and parse_header from Python 2.5.1 are used. (I simply copied them and added the required import.)

I also took the liberty of adding keep_blank_values=True for django.core.cache.get_cache and django.utils.simplejson.jsonfilter.JSONFilter.

The bugfixes for the functions parse_qsl and parse_header are included in Python 2.3.5 and up (see the comment in django.utils._cgi).

[arien <regexbot@…>]

The functions in django.utils._cgi should of course include "Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007 Python Software Foundation; All Rights Reserved" and maybe the History comment block from the original cgi.py. Including that somehow escaped me... :-(

[Chris Beaven]

Is it good enough to always use our version? Malcolm had said we should "use our version for 2.3" which I read as "only use our version for <2.4"

[Malcolm Tredinnick]

Our normal practice is to use Python's native version when it's sufficient. Providing the API we use is the same (which is why this rule doesn't apply to _doctest.py, for example), I think that should be the case here, too. Put the Django replacement in a compat file in django/utils and load that only if required. We might as well take advantage of all upstream fixes for more recent Python versions.

[Andy Durdin]

Attaching a new patch, with test. This one only uses the compatibility module when running on Python < 2.3.5 (it checks sys.version_info). As there have been further changes between 2.3.5 and 2.5.1 that I have not evaluated for 2.3.x compatibility, it makes more sense to me to just include the whole cgi module from 2.3.5.

[Andy Durdin]

Updated patch against r10680

[Jacob]

Django 1.2 won't support 2.3 any more, and those still on 1.1/2.3 should be upgrading to the latest 2.3 (2.3.7) anyway.