Skip to content

HTTP 400 likely not proper usage #37

@cxj

Description

@cxj

For your consideration:

It occurs to me a Responder should rarely ever convert an error status returned from a Domain object into an HTTP 400 status code. Presently, the model code does do this:

    protected function failure()
    {
        $this->response = $this->response->withStatus(400);
        $this->jsonBody($this->payload->getInput());
    }

Status 400 means a Bad Request was made by the client, most likely a web browser. If that were the case, such an error should be caught on input, most likely before any real application domain code is even executed. I can imagine a situation where one might have an Action class that checks client input in such a way that it might need to generate a Bad Request 400 response. But I think that's a fairly unusual case. As a writer on Stack Overflow put it:

Using 400 status codes for any other purpose than indicating that the request is malformed is just plain wrong.

Instead, status 500 is probably what is wanted in most cases where a Domain class returns some kind of error. Quoting the spec:

The 5xx (Server Error) class of status code indicates that the server is aware that it has erred or is incapable of performing the requested method. 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. A user agent SHOULD display any included representation to the user. These response codes are applicable to any request method.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions