This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Missing 507 response description
Type: enhancement Stage: resolved
Components: Documentation Versions: Python 3.5
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: berker.peksag Nosy List: Daniel.Andrade.Groppe, Filip.Malczak, SilentGhost, berker.peksag, demian.brecht, flox, martin.panter, orsenthil, python-dev, r.david.murray, rhettinger
Priority: normal Keywords: easy, patch

Created on 2014-03-12 15:14 by Filip.Malczak, last changed 2022-04-11 14:57 by admin. This issue is now closed.

File name Uploaded Description Edit
issue20898_with_doc.patch Daniel.Andrade.Groppe, 2014-03-17 02:40 review
issue20898.patch demian.brecht, 2015-01-05 16:15 review
Messages (22)
msg213266 - (view) Author: Filip Malczak (Filip.Malczak) Date: 2014-03-12 15:14
I find it strange, that in http.client module we have variable:
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.
msg213268 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-03-12 16:10
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...
msg213654 - (view) Author: Daniel Andrade Groppe (Daniel.Andrade.Groppe) * Date: 2014-03-15 14:24
Added missing constants and response status codes:

Response status codes:
102, 207, 208, 226, 308, 422, 423, 424, 426, 507, 508
msg213771 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-03-16 23:10
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).
msg213781 - (view) Author: Filip Malczak (Filip.Malczak) Date: 2014-03-16 23:59
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:
    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.
msg213786 - (view) Author: Daniel Andrade Groppe (Daniel.Andrade.Groppe) * Date: 2014-03-17 02:40
Here goes the patch once again, this time with the changes to the documentation.

Two files were modified:
1. /Lib/http/
2. /Doc/library/http.client.rst

Hope this helps until a decision is made on how to remove duplicate codes in http.clinet and http.server
msg220797 - (view) Author: Demian Brecht (demian.brecht) * (Python triager) Date: 2014-06-17 05:46
I actually made a similar change for issue #15025 earlier today. One of the two should likely be closed as a dupe.
msg223617 - (view) Author: Demian Brecht (demian.brecht) * (Python triager) Date: 2014-07-21 23:03
Being this is tagged for 3.5, I've refactored status codes as part of #21793. Should that be accepted and merged, that will also clear up this issue.
msg233230 - (view) Author: Demian Brecht (demian.brecht) * (Python triager) Date: 2014-12-31 09:14
The patch in #21793 has been merged, resolving this issue as well. This should now be closed.
msg233234 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2014-12-31 09:29
I think the documentation part of the patch is still useful.
msg233273 - (view) Author: Demian Brecht (demian.brecht) * (Python triager) Date: 2015-01-01 02:43
@Berker: Good point, although I think that the status code table in http.client.rst should be merged with the one in http.rst as to avoid redundancy (newly added status codes should also have links added). The table in http.client.rst should likely be replaced with a link to the newer one.
msg233465 - (view) Author: Demian Brecht (demian.brecht) * (Python triager) Date: 2015-01-05 16:15
The attached patch is a rework of the http.HTTPStatus docs to include links to the RFCs. While working through this, I noticed that I may have been a little overzealous in inclusion of some of the status codes. Some non-standard codes have been deprecated or collide between vendors. As such, I've removed non-standard codes. The only ones supported are those that are IANA-registered (including experimental codes). This is to reduce the chance of future conflicts. These were only recently added for 3.5 and therefore should not cause any backwards compatibility issues.
msg233466 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2015-01-05 17:00
LGTM. Great patch, thanks!
msg234095 - (view) Author: Demian Brecht (demian.brecht) * (Python triager) Date: 2015-01-15 19:21
Ping. Would be nice to get this change in before 3.5.0a1.
msg234106 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2015-01-16 01:37
This is mostly a documentation update. Documentation updates can be committed anytime. Also, feature freeze for 3.5 will be started by Beta 1, not Alpha 1 (see PEP 478).

I'll commit the patch this weekend. Thanks!
msg234339 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2015-01-20 04:30
New changeset c8647dab4780 by Berker Peksag in branch 'default':
Issue #20898: Add a "HTTP status codes" section to avoid duplication in HTTP docs.
msg234340 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2015-01-20 04:33
Committed now, sorry about the delay. Thanks for the patch, Demian.
msg234341 - (view) Author: Demian Brecht (demian.brecht) * (Python triager) Date: 2015-01-20 04:42
No worries, thanks for taking care of merging it Berker.
msg234349 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2015-01-20 05:38
Just noticed the new documentation says “http.HTTPStatus.OK is also available as . . . http.server.OK”. I think this is wrong; only the client module (and now the top-level package) have those constants. The enum values are only available in the server module via http.server.BaseHTTPRequestHandler.responses.keys() as far as I can tell.
msg234351 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2015-01-20 06:03
New changeset 3a95a74aca4e by Berker Peksag in branch 'default':
Issue #20898: Enum names are only available in the http.client module as constants.
msg234352 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2015-01-20 06:03
Good catch, thank you Martin.
msg254952 - (view) Author: SilentGhost (SilentGhost) * (Python triager) Date: 2015-11-20 07:16
Re msg233465: it doesn't seem like a particularly good justification to remove something that is not hurting anyone. The problem now is that because http.HTTPStatus is an enumeration, it cannot be extended, therefore when someone encounters these non-standard codes, the only option is to just use the integers. I trust what Demian is saying, that there might be some clashing between the non-standard codes, but until it's shown to be a problem removing real-world use cases just actively reduces usefulness of the library. For comparison, the module that is actually used by people includes the whole lot
Date User Action Args
2022-04-11 14:57:59adminsetgithub: 65097
2015-11-20 07:16:26SilentGhostsetnosy: + SilentGhost
messages: + msg254952
2015-01-20 06:03:38berker.peksagsetmessages: + msg234352
2015-01-20 06:03:07python-devsetmessages: + msg234351
2015-01-20 05:38:29martin.pantersetmessages: + msg234349
2015-01-20 04:42:23demian.brechtsetmessages: + msg234341
2015-01-20 04:33:13berker.peksagsetstatus: open -> closed
resolution: fixed
messages: + msg234340

stage: commit review -> resolved
2015-01-20 04:30:44python-devsetnosy: + python-dev
messages: + msg234339
2015-01-16 01:37:02berker.peksagsetmessages: + msg234106
2015-01-15 19:21:00demian.brechtsetmessages: + msg234095
2015-01-05 17:00:05berker.peksagsetassignee: berker.peksag
messages: + msg233466
2015-01-05 16:15:50demian.brechtsetfiles: + issue20898.patch

messages: + msg233465
2015-01-04 00:17:49rhettingersetassignee: rhettinger -> (no value)
2015-01-01 02:43:46demian.brechtsetmessages: + msg233273
2014-12-31 09:29:10berker.peksagsetnosy: + berker.peksag
messages: + msg233234

components: + Documentation, - Extension Modules
stage: commit review
2014-12-31 09:14:22demian.brechtsetmessages: + msg233230
2014-07-21 23:03:40demian.brechtsetmessages: + msg223617
2014-07-05 17:33:48floxsetnosy: + flox
2014-06-21 03:04:27rhettingersetassignee: rhettinger

nosy: + rhettinger
2014-06-17 05:46:07demian.brechtsetnosy: + demian.brecht
messages: + msg220797
2014-03-19 01:50:00martin.pantersetnosy: + martin.panter
2014-03-17 02:40:47Daniel.Andrade.Groppesetfiles: + issue20898_with_doc.patch

messages: + msg213786
2014-03-17 02:35:42Daniel.Andrade.Groppesetfiles: - issue20898.patch
2014-03-16 23:59:00Filip.Malczaksetmessages: + msg213781
2014-03-16 23:10:57r.david.murraysetnosy: + orsenthil

messages: + msg213771
versions: + Python 3.5
2014-03-15 14:24:35Daniel.Andrade.Groppesetfiles: + issue20898.patch

type: behavior -> enhancement
components: + Extension Modules, - Library (Lib)

keywords: + patch
nosy: + Daniel.Andrade.Groppe
messages: + msg213654
2014-03-12 16:17:14benjamin.petersonsetkeywords: + easy
components: + Library (Lib), - IO
2014-03-12 16:10:44r.david.murraysetnosy: + r.david.murray
messages: + msg213268
2014-03-12 15:15:42Filip.Malczaksettitle: Missin 507 response description -> Missing 507 response description
2014-03-12 15:14:04Filip.Malczakcreate