Repository navigation
multiple issues in http.client #69926
Description
| BPO | 25740 |
|---|---|
| Nosy | @vadmium, @spaceone |
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 = None
created_at = <Date 2015-11-27.00:35:22.170>
labels = ['type-bug', 'library']
title = 'multiple issues in http.client'
updated_at = <Date 2015-11-27.02:50:35.343>
user = 'https://github.com/spaceone'bugs.python.org fields:
activity = <Date 2015-11-27.02:50:35.343>
actor = 'martin.panter'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2015-11-27.00:35:22.170>
creator = 'spaceone'
dependencies = []
files = []
hgrepos = []
issue_num = 25740
keywords = []
message_count = 3.0
messages = ['255445', '255449', '255450']
nosy_count = 2.0
nosy_names = ['martin.panter', 'spaceone']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue25740'
versions = ['Python 2.7', 'Python 3.4', 'Python 3.5', 'Python 3.6']
Activity
spaceone commentedon Nov 27, 2015
Patch: spaceone/cpython@3289080
Part of github Pull Request #19 from July. Should I split this up into multiple bugtracker issues?
vadmium commentedon Nov 27, 2015
Thanks for these fixes. It might be better to open other report(s) for the FIXME comments, so you can explain them better, and propose any ideas or possible solutions. For some of them, it may be more appropriate to just fix them in the next (3.6) release, such as the method case insensitivity thing (to minimize backwards compatibility problems).
It would be good to have regression test cases for each bug fixed.
Regarding folded header field values, I think there was some discussion about deprecating that ability in bpo-22928. Definitely needs a separate report.
See bpo-23740 about various quirks with what objects and automatic encodings are accepted when sending a request. It is already a can of worms; I suggest not to make it any more complicated.
Can you elaborate on accepting invalid ports? Is this related to bpo-24169?
vadmium commentedon Nov 27, 2015
I missed seeing the _get_hostport() change in the commit. So you are saying that values out of range 1–65535 should raise InvalidURL("nonnumeric port . . ."). The error message isn’t quite right.