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.

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...

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

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).

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.

Here goes the patch once again, this time with the changes to the documentation.

Two files were modified:
1. /Lib/http/client.py
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

I actually made a similar change for issue #15025 earlier today. One of the two should likely be closed as a dupe.

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.

The patch in #21793 has been merged, resolving this issue as well. This should now be closed.

I think the documentation part of the patch is still useful.

@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.

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.

LGTM. Great patch, thanks!

Ping. Would be nice to get this change in before 3.5.0a1.

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!

New changeset c8647dab4780 by Berker Peksag in branch 'default':
Issue #20898: Add a "HTTP status codes" section to avoid duplication in HTTP docs.
https://hg.python.org/cpython/rev/c8647dab4780

Committed now, sorry about the delay. Thanks for the patch, Demian.

No worries, thanks for taking care of merging it Berker.

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.

New changeset 3a95a74aca4e by Berker Peksag in branch 'default':
Issue #20898: Enum names are only available in the http.client module as constants.
https://hg.python.org/cpython/rev/3a95a74aca4e

Good catch, thank you Martin.

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 https://github.com/kennethreitz/requests/blob/master/requests/status_codes.py