Opened 13 years ago

Closed 9 years ago

#1201 closed defect (wontfix)

query string parsing problem

Reported by: Eric Moritz Owned by: Andy Durdin
Component: Core (Other) Version:
Severity: normal Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


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/ 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.

Attachments (2)

1201.diff (6.6 KB) - added by arien <regexbot@…> 11 years ago.
1201.2.diff (37.7 KB) - added by Andy Durdin 10 years ago.
Updated patch against r10680

Download all attachments as: .zip

Change History (15)

comment:1 Changed 13 years ago by Adrian Holovaty

Hey Eric, could you provide the patch?

comment:2 Changed 12 years ago by Simon G. <dev@…>

Triage Stage: UnreviewedDesign decision needed

comment:3 Changed 12 years ago by Malcolm Tredinnick

Triage Stage: Design decision neededAccepted

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.

Changed 11 years ago by arien <regexbot@…>

Attachment: 1201.diff added

comment:4 Changed 11 years ago by arien <regexbot@…>

Has patch: set

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).

comment:5 Changed 11 years ago by 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 Including that somehow escaped me... :-(

comment:6 Changed 11 years ago by foobarmus

Owner: changed from nobody to foobarmus
Status: newassigned

comment:7 Changed 11 years ago by Chris Beaven

Triage Stage: AcceptedDesign decision needed

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"

comment:8 Changed 11 years ago by 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, 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.

comment:9 Changed 11 years ago by Chris Beaven

Patch needs improvement: set
Triage Stage: Design decision neededAccepted

comment:10 Changed 11 years ago by Adrian Holovaty

Needs tests: set

comment:11 Changed 10 years ago by anonymous

Owner: changed from foobarmus to Andy Durdin
Status: assignednew

comment:12 Changed 10 years ago by Andy Durdin

Needs tests: unset
Patch needs improvement: unset

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.

Changed 10 years ago by Andy Durdin

Attachment: 1201.2.diff added

Updated patch against r10680

comment:13 Changed 9 years ago by Jacob

Resolution: wontfix
Status: newclosed

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.

Note: See TracTickets for help on using tickets.
Back to Top