parse_qsl fails on empty query argument without =

[DavidPizzuto]

BPO	19951
Nosy	@bitdancer

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2013-12-11.18:43:06.361>
created_at = <Date 2013-12-11.18:11:45.094>
labels = ['type-bug', 'invalid']
title = 'parse_qsl fails on empty query argument without ='
updated_at = <Date 2013-12-11.18:43:06.360>
user = 'https://bugs.python.org/DavidPizzuto'

bugs.python.org fields:

activity = <Date 2013-12-11.18:43:06.360>
actor = 'r.david.murray'
assignee = 'none'
closed = True
closed_date = <Date 2013-12-11.18:43:06.361>
closer = 'r.david.murray'
components = []
creation = <Date 2013-12-11.18:11:45.094>
creator = 'David.Pizzuto'
dependencies = []
files = []
hgrepos = []
issue_num = 19951
keywords = []
message_count = 2.0
messages = ['205911', '205913']
nosy_count = 2.0
nosy_names = ['r.david.murray', 'David.Pizzuto']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue19951'
versions = ['Python 2.7', 'Python 3.2']

[DavidPizzuto]

Using an empty query argument with no = fails in urlparse.parse_qsl. Chrome and Firefox accept it without the =, so a navigation to google.com/search?q=foo&bar appears in the address bar as google.com/search?q=foo&bar=. Neither RFC 1738 nor RFC 3986 define the format of query strings. Wikipedia is similarly silent.

I can reproduce in 2.7.3 and 3.2.3, as shown below. I'm told this is also true of 3.3 but don't have easy access to a 3.3 interpreter to confirm.

The obvious workaround is to simply set strict_parsing=False, but I don't know what other checks that's disabling. Would it be reasonable to change parse_qsl to add the = if it's not present?

$ python
Python 2.7.3 (default, Sep 26 2013, 20:03:06) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import urlparse
>>> query = 'foo&bar=baz'
>>> urlparse.parse_qs(query, strict_parsing=True, keep_blank_values=True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/urlparse.py", line 353, in parse_qs
    for name, value in parse_qsl(qs, keep_blank_values, strict_parsing):
  File "/usr/lib/python2.7/urlparse.py", line 387, in parse_qsl
    raise ValueError, "bad query field: %r" % (name_value,)
ValueError: bad query field: 'foo'

$ python3
Python 3.2.3 (default, Sep 25 2013, 18:22:43) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib.parse
>>> query = 'foo&bar=baz'
>>> urllib.parse.parse_qs(query, strict_parsing=True, keep_blank_values=True)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.2/urllib/parse.py", line 556, in parse_qs
    encoding=encoding, errors=errors)
  File "/usr/lib/python3.2/urllib/parse.py", line 596, in parse_qsl
    raise ValueError("bad query field: %r" % (name_value,))
ValueError: bad query field: 'foo'

[bitdancer]

I did some research on this for a previous issue, and every description of query strings I could find agreed that the format was '<name>=<value>'. That is, that the '=' is not optional, even though some servers (note, *not* browsers, they just transmit or display the URI provided by the user or server) will accept parameters without the '=' and treat them as if they had one.

So I think this being rejected by strict_parsing is correct. I'm closing this as invalid.

As for what strict_parsing, controls, you can check the source. It looks like this and empty arguments (ie: &&) are the only things it controls.