Repository navigation
Content-Type when sending data with urlopen() #67549
Description
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 2021-12-06.00:08:26.531>
created_at = <Date 2015-02-01.12:43:32.468>
labels = ['docs']
title = 'Content-Type when sending data with urlopen()'
updated_at = <Date 2021-12-06.00:08:26.531>
user = 'https://github.com/vadmium'bugs.python.org fields:
activity = <Date 2021-12-06.00:08:26.531>
actor = 'iritkatriel'
assignee = 'docs@python'
closed = True
closed_date = <Date 2021-12-06.00:08:26.531>
closer = 'iritkatriel'
components = ['Documentation']
creation = <Date 2015-02-01.12:43:32.468>
creator = 'martin.panter'
dependencies = []
files = ['37959', '37972', '38758', '40968', '40969', '43428']
hgrepos = []
issue_num = 23360
keywords = ['patch']
message_count = 8.0
messages = ['235166', '235219', '238811', '239684', '254258', '254259', '268708', '407143']
nosy_count = 7.0
nosy_names = ['orsenthil', 'r.david.murray', 'docs@python', 'martin.panter', 'serhiy.storchaka', 'demian.brecht', 'iritkatriel']
pr_nums = []
priority = 'normal'
resolution = 'out of date'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue23360'
versions = ['Python 2.7', 'Python 3.5', 'Python 3.6']
Activity
vadmium commentedon Feb 1, 2015
Currently the documentation gives the impression that the “data” parameter to Request() has to be in the application/x-www-form-urlencoded format. However I suspect that you can override the type by supplying a Content-Type header, and I would like to document this; see uploaded patch.
I noticed that test_urllib2.HandlerTests.test_http() already seems to test the default Content-Type and a custom Content-Type with a Request() object, although I did not see a test for the default Content-Type when supplying “data” directly to urlopen().
Also I understand the “charset” parameter on application/x-www-form-urlencoded is not standardized. Would it correspond to the encoding of the %XX codes from urlencode(), which is typically UTF-8, not Latin-1? Or would it correspond to the subsequent string-to-bytes encoding stage, which could just be ASCII since non-ASCII characters are already encoded? Maybe it would be best to drop the advice to set a “charset” parameter. It was added for bpo-11082.
vadmium commentedon Feb 2, 2015
Updated patch to explain that a Request object is generated internally for urlopen(data=...), and added a test to confirm. Also removed some confusing dead code.
serhiy-storchaka commentedon Mar 21, 2015
The documentation looks contradictory. "The *data* argument must be", but "The *data* argument may also be". "must be a bytes object", but "If *data* is a buffer".
Why not write just "The data argument must be a bytes-like object, an iterable of bytes-like objects, or None"? It doesn't depend if url is a string or a Request object.
AFAIK the data argument of Request can be an iterable of bytes-like objects in additional to a bytes-like object or None.
The note about the application/x-www-form-urlencoded format is applied not only to a bytes object, but to an iterable of bytes-like objects too. I.e. to any acceptable value except None.
vadmium commentedon Mar 31, 2015
I think we should avoid mentioning bytes-like objects until bpo-23740 (http.client support), bpo-23756 (clarify definition), and/or SSLSocket.sendall() support are sorted out.
Changes in non-urlencoded.3.patch:
vadmium commentedon Nov 7, 2015
Patch 4 is just updated to avoid conflicts with the current code. Changes are the same.
vadmium commentedon Nov 7, 2015
Spotted a docstring that needed updating
vadmium commentedon Jun 17, 2016
Fixed conflicts with recent changes
iritkatriel commentedon Nov 27, 2021
Martin, I think you fixed this in
3c0d0ba#diff-533bd604631e0e26ce55dfa75a878788f3c4d7d7ccb3bbaeaa2ee2a9c956ffe8