I believe a fundamental difference between the 500 and 503 error response
is that the 503 response is machine readable regardless of any extra text
or html the server might return with the response as content. That is, a
client or proxy that receives a 503 message knows that the remote server is
currently unavailable because it is too busy. If you just wanted a human
readable response, then a 500 response would suffice as long as the Web
client displayed that message to the user, not all clients do.
While, I don't wish to create a separate server response for every
eventuality (Henrik's point is well taken) I do believe that we need some
way of conveying machine readable semantics in the server response as a
fundamental piece of quality of service.
Since the headers are currently a flat information space, the obvious thing
to do is create a new header response for something like a busy remote
server. Perhaps the guideline for adding a new response should be whether
making the response machine readable makes any sense versus just displaying
a response to the user which requires them to take some action. This
implies that clients always display a 5xx response to the user if an
automatic action is not possible. This fits with our current model for
response codes in the 2xx, 3xx, and 4xx classes as well.
ka