http client error

[cober]

BPO	5314
Files	client.py: http.client

^{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 2009-03-27.21:20:32.369>
created_at = <Date 2009-02-19.09:05:00.606>
labels = ['build', 'library']
title = 'http client error'
updated_at = <Date 2009-03-27.21:20:32.333>
user = 'https://bugs.python.org/cober'

bugs.python.org fields:

activity = <Date 2009-03-27.21:20:32.333>
actor = 'jhylton'
assignee = 'jhylton'
closed = True
closed_date = <Date 2009-03-27.21:20:32.369>
closer = 'jhylton'
components = ['Library (Lib)']
creation = <Date 2009-02-19.09:05:00.606>
creator = 'cober'
dependencies = []
files = ['13136']
hgrepos = []
issue_num = 5314
keywords = []
message_count = 5.0
messages = ['82465', '84227', '84279', '84280', '84281']
nosy_count = 2.0
nosy_names = ['jhylton', 'cober']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = 'compile error'
url = 'https://bugs.python.org/issue5314'
versions = ['Python 3.1']

[cober]

Try to use http to send multi-byte utf8 data.

File "E:\DEVELOP\python\lib\http\client.py", line 904, in _send_request
self.endheaders(body.encode('ascii'))
UnicodeEncodeError: 'ascii' codec can't encode character '\u7231' in
position 119: ordinal not in range(128)

I modified the lib/http/client.py document, and fix this problem.

[jhylton]

I'm not sure what to do here. I guess changing to utf-8 is safe insofar
as the current code only accepts ascii, so the only code that breaks
will be code that depends on the encode() call raising an exception. It
seems like the client out to specify the encoding, though. We could fix
that via documentation.

[jhylton]

The documentation is pretty vague on this point. If you send something
other than plain ascii, it gets a bit tricky to figure out what other
headers need to be added. It would be safer for the client to pick an
encoding (e.g. utf-8) and encode the string before calling request().
It affects the content-length and presumably also the content-type.

[jhylton]

Ok. Discovered that RFC 2616 says that iso-8859-1 is the default
charset, so I will use that to encode strings instead of ascii. If you
want utf-8, you could encode the string yourself before calling
request(). Presumably, you should also add a content-type that explains
the charset. I'll clarified this in the docs.

[jhylton]

Committed revision 70638.