Missing 507 response description

[FilipMalczak]

BPO	20898
Nosy	@rhettinger, @orsenthil, @bitdancer, @florentx, @berkerpeksag, @vadmium, @demianbrecht, @dangro
Files	issue20898_with_doc.patch issue20898.patch

^{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 = 'https://github.com/berkerpeksag'
closed_at = <Date 2015-01-20.04:33:13.268>
created_at = <Date 2014-03-12.15:14:04.221>
labels = ['easy', 'type-feature', 'docs']
title = 'Missing 507 response description'
updated_at = <Date 2015-11-20.07:16:26.701>
user = 'https://bugs.python.org/FilipMalczak'

bugs.python.org fields:

activity = <Date 2015-11-20.07:16:26.701>
actor = 'SilentGhost'
assignee = 'berker.peksag'
closed = True
closed_date = <Date 2015-01-20.04:33:13.268>
closer = 'berker.peksag'
components = ['Documentation']
creation = <Date 2014-03-12.15:14:04.221>
creator = 'Filip.Malczak'
dependencies = []
files = ['34450', '37604']
hgrepos = []
issue_num = 20898
keywords = ['patch', 'easy']
message_count = 22.0
messages = ['213266', '213268', '213654', '213771', '213781', '213786', '220797', '223617', '233230', '233234', '233273', '233465', '233466', '234095', '234106', '234339', '234340', '234341', '234349', '234351', '234352', '254952']
nosy_count = 11.0
nosy_names = ['rhettinger', 'orsenthil', 'r.david.murray', 'SilentGhost', 'flox', 'python-dev', 'berker.peksag', 'martin.panter', 'demian.brecht', 'Filip.Malczak', 'Daniel.Andrade.Groppe']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue20898'
versions = ['Python 3.5']

[FilipMalczak]

I find it strange, that in http.client module we have variable:
INSUFFICIENT_STORAGE = 507
yet in responses (dict mapping int codes to descriptions) 507 is missing.

It's probably just mistake caused by short dev memory, fix is easy: add line:
507: 'Insufficient storage',
between lines 208 and 209 (just after mapping for 505).

Sorry, if this isn't well formatted issue, or if I specified wrong metadata.

I'm working on Python 3.3.2+ (automatically installed in LUbuntu 13.10), and I don't know whether it was fixed in later versions.

[bitdancer]

Looks like that's not the only code that was missed (I see 102 is also not listed).

What happened was that the responses table was originally part of urllib2, and was moved into httplib (back when it was httplib). But httplib had more response codes in it than the urllib2 did, apparently.

I think it makes sense to make them consistent (add the missing ones to responses), even though it is not clear that the constants are used anywhere.

I wonder if it makes sense to use an Enum here somehow...

[dangro]

Added missing constants and response status codes:
Constants:
ALREADY_REPORTED, PERMANENT_REDIRECT, LOOP_DETECTED

Response status codes:
102, 207, 208, 226, 308, 422, 423, 424, 426, 507, 508

[bitdancer]

Thanks. That patch looks good except that it is missing the corresponding documentation changes, but...

I just noticed that this table is a partial duplicate of the table in http.server. I suspect this has historical origins, but I don't see any reason to maintain the duplication. I wonder if we should do some refactoring here. This is getting a beyond the original scope of this issue, but it seems to me that the common stuff used by http.server and http.client (which is mostly in http.client, except for the 'explain' messages that are in the http.server responses list) could be moved into a 'common' or 'util' module, and imported from both, thus reducing the direct coupling between http.server and http.client. (The 'responses' object in http.client would have to be computed from the one in this new module, since the http.client one doesn't contain the 'explain' messages).

[FilipMalczak]

If we're getting out of original scope, then I wonder... Maybe we should keep only standard status codes here? If not, which should we support, and which not? What about custom Spring 420 Method Failure?

One way to clean up mess here is to create some dictionaries called Http09, Http10, Http11, but also Nginx, Spring, InternetDraft, etc - they would hold codes specific to some standard or extension (and they should be incremental, so Http11 would hold only those codes that came with HTTP 1.1, not any of HTTP 1.0 codes).

Also, we should provide function responses_mapping which should take dictionaries with code mappings, so one may use it like responses_mapping(Http09, Http10, Http11, Spring). Module attribute responses should be initialized to responses_mapping(Http09, Http10, Http11), so it would contain standard codes only.

responses_mapping (we should probably consider different name) should take any number of dicts, merge them and return merging result. Additionally, I think it should overwrite merged values, so if we call it with two dicts, which hold the same key - value from last dict with this key should be used. Essentially, it is just:
def responses_mapping(*dicts):
out = {}
for d in dicts:
out.update(d)
return out

Now, we would have clean responses dictionary (mentioned in first comment, one that started this issue), and possibility to extend responses set with different protocol and extension versions.

There may be one problem - many apps and libs (possibly standard python library too) may use keys from out of HTTP standard, so this change could break backwards compability.