Martin Panter added the comment: This change is a result of parameter checking added in Issue 22928. The colon is not meant to be part of a field name. This is what the request being sent by your example looks like in the unpatched 3.4. (I changed to localhost.) Your attempt to override the default Content-Type is not working due to the colon:
POST /xrbl82xr HTTP/1.1 Accept-Encoding: identity Content-Type: application/x-www-form-urlencoded Host: localhost User-Agent: Python-urllib/3.4 Content-Length: 21 Content-Type:: application/x-www-form-urlencoded;charset=utf-8 Connection: close spam=1&eggs=2&bacon=0 So I don’t think this is a valid bug or regression. What gave you the idea to include the colon? Does the documentation need clarifying? Also, I would recommend not trying to set a “charset” attribute with the form-urlencoded content type in general. It is not standardized, and I proposed to remove the recommendation from the documentation in Issue 23360 (feedback welcome). If you really need to send non-ASCII data, you might be able to get away with UTF-8 by default. Also, HTML 5 mentions a _charset_ field, and there is the multipart/form-data content type. ---------- nosy: +martin.panter stage: needs patch -> type: crash -> behavior _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25570> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
