Opened 10 years ago

Closed 7 years ago

#1201 closed defect (wontfix)

query string parsing problem

Reported by: Eric Moritz Owned by: adurdin
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: UI/UX:


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@…> 9 years ago.
1201.2.diff (37.7 KB) - added by adurdin 7 years ago.
Updated patch against r10680

Download all attachments as: .zip

Change History (15)

comment:1 Changed 10 years ago by adrian

Hey Eric, could you provide the patch?

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

  • Triage Stage changed from Unreviewed to Design decision needed

comment:3 Changed 9 years ago by mtredinnick

  • Triage Stage changed from Design decision needed to Accepted

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 9 years ago by arien <regexbot@…>

comment:4 Changed 9 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 9 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 9 years ago by foobarmus

  • Owner changed from nobody to foobarmus
  • Status changed from new to assigned

comment:7 Changed 8 years ago by SmileyChris

  • Triage Stage changed from Accepted to Design 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 8 years ago by mtredinnick

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 8 years ago by SmileyChris

  • Patch needs improvement set
  • Triage Stage changed from Design decision needed to Accepted

comment:10 Changed 8 years ago by adrian

  • Needs tests set

comment:11 Changed 7 years ago by anonymous

  • Owner changed from foobarmus to adurdin
  • Status changed from assigned to new

comment:12 Changed 7 years ago by adurdin

  • 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 7 years ago by adurdin

Updated patch against r10680

comment:13 Changed 7 years ago by jacob

  • Resolution set to wontfix
  • Status changed from new to closed

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