| 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: 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. |
|
|
| msg213268 - (view) |
Author: R. David Murray (r.david.murray) *  |
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: Constants: ALREADY_REPORTED, PERMANENT_REDIRECT, LOOP_DETECTED Response status codes: 102, 207, 208, 226, 308, 422, 423, 424, 426, 507, 508 |
|
|
| msg213771 - (view) |
Author: R. David Murray (r.david.murray) * |
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: 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. |
|
|
| 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/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 |
|
|
| msg220797 - (view) |
Author: Demian Brecht (demian.brecht) *  |
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) * |
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) * |
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) * |
Date: 2014-12-31 09:29 |
| I think the documentation part of the patch is still useful. |
|
|
| msg233273 - (view) |
Author: Demian Brecht (demian.brecht) * |
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) * |
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) * |
Date: 2015-01-05 17:00 |
| LGTM. Great patch, thanks! |
|
|
| msg234095 - (view) |
Author: Demian Brecht (demian.brecht) * |
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) * |
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) |
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. https://hg.python.org/cpython/rev/c8647dab4780 |
|
|
| msg234340 - (view) |
Author: Berker Peksag (berker.peksag) * |
Date: 2015-01-20 04:33 |
| Committed now, sorry about the delay. Thanks for the patch, Demian. |
|
|
| msg234341 - (view) |
Author: Demian Brecht (demian.brecht) * |
Date: 2015-01-20 04:42 |
| No worries, thanks for taking care of merging it Berker. |
|
|
| msg234349 - (view) |
Author: Martin Panter (martin.panter) * |
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) |
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. https://hg.python.org/cpython/rev/3a95a74aca4e |
|
|
| msg234352 - (view) |
Author: Berker Peksag (berker.peksag) * |
Date: 2015-01-20 06:03 |
| Good catch, thank you Martin. |
|
|
| msg254952 - (view) |
Author: SilentGhost (SilentGhost) * |
Date: 2015-11-20 07:16 |
| Re : 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 |
|
|