[issue20898] Missing 507 response description

Filip Malczak report at bugs.python.org
Mon Mar 17 00:59:00 CET 2014


Filip Malczak added the comment:

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.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20898>
_______________________________________


More information about the Python-bugs-list mailing list