Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTTP 400 likely not proper usage #37

Open
cxj opened this issue Nov 18, 2017 · 2 comments
Open

HTTP 400 likely not proper usage #37

cxj opened this issue Nov 18, 2017 · 2 comments

Comments

@cxj
Copy link
Contributor

cxj commented Nov 18, 2017

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.

@cxj
Copy link
Contributor Author

cxj commented Mar 9, 2018

I think maybe the notional mapping of the Aura\Payload_Interface\PayloadStatus values, which are distinct to domain objects, into HTTP status codes in Radar\Adr\Responder in method getMethodForPayload() is flawed. A Domain object could intelligently return a value of FAILURE that indicated some condition which only the Domain considers a failure, but which from the HTTP Responder's point of view is expected. At a minimum, it would almost certainly not be the result of a malformed HTTP request. Yet, present code maps this Domain status into HTTP 400, which means exactly that (malformed). It seems like there needs to be more sophistication in this mapping, and probably it will be somewhat application dependent.

@cxj
Copy link
Contributor Author

cxj commented Feb 8, 2019

In my final* design, I ended up mapping almost everything to HTTP 200 and instead using Responder classes and templates to display useful error messages to users.

*nothing is ever really finished, right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant