Support non-standard response codes

[davidfells]

It's not unsual for APIs, especially private ones, to use non-standard response codes in the 400 range for specific errors. As is, the module does not allow this - it will convert any non-standard code to a 500. As an example here's what I'm doing in my app:

  var err = http_errors(471, 'Invalid API Key.')
  err.status = 471;

Ideally, in my opinion, there would be a way to pass an array of additional codes when requiring the library, which would allow us to easily have a JSON file containing our extended error codes while allowing the library to validate the code against the list of available/valid codes.

[hacksparrow]

What would be the value of err.name in such a case?

• Unassigned
• NonStandardError
• CustomError
• Error
• ?

[jonathanong]

maybe we should add jshttp/statuses#5 and allow for custom err.name for each status code?

[dougwilson]

For @hacksparrow question, we can just treat it like the x00 class name, from https://tools.ietf.org/html/rfc7231#section-6

HTTP status codes are extensible. HTTP clients are not required to
understand the meaning of all registered status codes, though such
understanding is obviously desirable. However, a client MUST
understand the class of any status code, as indicated by the first
digit, and treat an unrecognized status code as being equivalent to
the x00 status code of that class, with the exception that a
recipient MUST NOT cache a response with an unrecognized status code.

For example, if an unrecognized status code of 471 is received by a
client, the client can assume that there was something wrong with its
request and treat the response as if it had received a 400 (Bad
Request) status code. The response message will usually contain a
representation that explains the status.