Non-standard HTTP status codes?

According to [Wikipedia](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes) and [MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status), the following status codes are not defined yet available through `requests`

https://github.com/psf/requests/blob/b227e3cb82c8d42ea27790d615ecafe12528d3bc/requests/status_codes.py#L32
https://github.com/psf/requests/blob/b227e3cb82c8d42ea27790d615ecafe12528d3bc/requests/status_codes.py#L84-L87
https://github.com/psf/requests/blob/b227e3cb82c8d42ea27790d615ecafe12528d3bc/requests/status_codes.py#L89
https://github.com/psf/requests/blob/b227e3cb82c8d42ea27790d615ecafe12528d3bc/requests/status_codes.py#L100

The above `444` and `499` seem to be from the [unofficial nginx errors](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#nginx)?

In addition, [`508` Loop Detected](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/508) is missing from that list.

I think it would help to document this in some more detail.

> I think it would help to document this in some more detail.

What detail do you feel is required? Would it be simpler to ignore non-official but fairly widely used status codes here and remove them if this is so confusing?

In addition to some documentation explaining the source of the extra codes, perhaps we can have other dictionaries of codes, such as an `_nginx_codes` dictionary that can be, by default, added to the `_codes` dictionary at [init](https://github.com/psf/requests/blob/b227e3cb82c8d42ea27790d615ecafe12528d3bc/requests/status_codes.py#L107). If users don't want nginx codes, they can set an environment variable or use some method to set a preference at runtime.
Would this make sense?
It would make the error codes available more modular, and wouldn't break backwards compatibility, as the full list of codes will be used by default.

Makes a lot of sense 👍🏼 

Want a PR for that?

I think we're probably moving in the wrong direction. These definitions have been around for a decade and remained relatively untouched. Many of them were added for fun long before Requests had its current adoption level. You'll find common codes have non-standard values added as well. e.g. `'okay', 'all_ok', 'all_okay', 'all_good', '\\o/', '✓'` will never be emitted from a common server for HTTP 200. We already have some of these marked for removal/updates with a new major version.

For the time being, these are here primarily for reference and have minimal impact on usage of the library. Adding more documentation/code will likely be noise that isn't be helpful for the average user. I'd be more inclined to leave things alone unless there's a concrete proposal on why they're inhibiting use of Requests.

@nateprewitt actually I found them very helpful for testing, so having an accurate list of HTTP codes and a few uncommon, sorted lists too, would help to write better tests — and use the `requests` package to provide tests.

Bringing this particular module forward would be a useful value-add, methinks.

Maybe adding a PR to see proposed changes helps the conversation? Shall I just go ahead with at and we can take it from there?

>  and use the `requests` package to provide tests.

I don't understand this. This package doesn't provide a testing framework and isn't intended as that purpose. Why would we accept a PR that is aimed towards that goal?


> This package doesn't provide a testing framework and isn't intended as that purpose.

It doesn’t, but it provides useful — somewhat incomplete, muddled up — information we use for testing: a collection of HTTP status codes. Hence the initial question…

Earlier, I was trying to make sense of you request by clarifying and adding on to it. Right now, it wouldn't make sense to edit code because there are some non-standard HTTP status codes. The most that may be reasonable to do is to add a line [here](https://github.com/psf/requests/blob/master/requests/status_codes.py#L20) stating that some status codes are non-standard and may be Nginx specific, and including a reference to MDN for status code information. However, that wouldn't really be necessary, since Requests is used as an HTTP utility, not a platform to teach users about HTTP. Does that help any?
Also, as a side-note, I believe adding features is [not allowed](https://github.com/psf/requests/issues/5814#issuecomment-838288432), so adding code for a completely new feature would likely not be accepted.

For the sake of illustration and to have something more concrete to discuss, I opened draft PR https://github.com/psf/requests/pull/5895.

I left feedback in #5895. I would encourage anyone interested in establishing a separate package to manage these status code lists which may prove to be useful in other testing tools. The `codes` module in Requests is ultimately a fun after thought and not intended to be a core part of the library. If we make any future changes to it, they should be to correct inaccurate information, and remove non-standard content. Those would need to wait until a major release though as stated above.