0

I want to notify a client of a specific error condition using a HTTP status code.

The closest I can come by is "416 Range Not Satisfiable" - although the service has nothing to do with serving byte-ranges from files.

Can I liberally interpret the meaning of "Range Not Satisfiable" or must I respect the technical definition involving byte-ranges of files?

aaa90210
  • 11,295
  • 13
  • 51
  • 88
  • Better to use a generic "Bad Request" status code and include details in the response body (or the error message line). – Thilo Nov 04 '16 at 02:00

1 Answers1

1

You can liberally interpret that. However, that doesn't make it the correct thing to do.

Errors that aren't specifically handled by the current 4xx set generally use the more generic 400 error along with an added explanation as to why. The general rule is that, if your error is an exact match to the more specific code, use it, otherwise use the less specific code.

Overloading the meaning of the specific codes is likely to lead to mass confusion.

As per RFC7231, section 6.5 (my italics):

The 4xx (Client Error) class of status code indicates that the client seems to have erred. Except when responding to a HEAD request, the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents SHOULD display any included representation to the user.

Community
  • 1
  • 1
paxdiablo
  • 854,327
  • 234
  • 1,573
  • 1,953
  • The problem is if you have a series of proxies, api gateways etc. many could/would return 400 codes with varying representations for other reasons. I would like to use a status code that can unambiguously be assumed to be from my service for a given URL to make it easier for the client to interpret the response. – aaa90210 Nov 04 '16 at 02:13
  • 1
    @aaa90210, then I suggest you join the IETF and convince them to add the `499 Specific code for aaa90210 to minimise their coding effort` status code :-) Anything else will be violating the standards, as so many other clowns have done before (https://en.wikipedia.org/wiki/List_of_HTTP_status_codes). It should be a simple matter for you to insert a *very* specific message into the response body, one which can be easily interpreted by code or user (such as `ERR314159 - no peeking allowed`). – paxdiablo Nov 04 '16 at 02:23
  • Seconded. Be _of_ the web. See RFC 7233. – VoiceOfUnreason Nov 04 '16 at 02:29
  • @paxdiablo well I am writing the service not the client :-) The client is very black-boxy and is deeply unimpressed by responses that don't match the schema it expects the service to return. The problem is many proxies/gateways I don't control may be put in front of the service and could easily return 400/500 with their own representations. It would be nice then if there was a "499 Backend Service Error" that would never, ever be returned by proxy/gateway, but would otherwise have the same meaning as 400. – aaa90210 Nov 04 '16 at 02:40
  • @aaa90210, you can use 499, there's just no guarantee nothing else won't be using it. It's similar to unassigned port numbers in that respect. Me, I'd prefer to follow the standards or at least notify the client of the potential issues. If they still want to go ahead after that, at least you warned them. – paxdiablo Nov 04 '16 at 03:41