Message254238
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. |
|
Date |
User |
Action |
Args |
2015-11-06 23:15:25 | martin.panter | set | recipients:
+ martin.panter, r.david.murray, crickert |
2015-11-06 23:15:25 | martin.panter | set | messageid: <1446851725.79.0.325343385277.issue25570@psf.upfronthosting.co.za> |
2015-11-06 23:15:25 | martin.panter | link | issue25570 messages |
2015-11-06 23:15:25 | martin.panter | create | |
|