HTTP status code != API Problem status

[snapshotpl]

When I throw exception in resource:

throw new \Exception('Error', 4000010);

I get:

• 500 in HTTP status code
• 4000010 in API problem status (content)

Apigility documentation says (https://apigility.org/documentation/api-primer/error-reporting):

status: the HTTP status code for the current request (optional; Apigility always provides this).

And API problem documentation (https://tools.ietf.org/html/draft-nottingham-http-problem-06):

"status" (number) - The HTTP status code ([RFC2616], Section 6) generated by the origin server for this occurrence of the problem. The status member, if present, is only advisory; it conveys the HTTP status code used for the convenience of the consumer. Generators MUST use the same status code in the actual HTTP response, to assure that generic HTTP software that does not understand this format still behaves correctly.

BTW Response after

throw new \Exception('Error', 200);

looks funny :-)

[snapshotpl]

@weierophinney can you look at this issue? It's looks seriously

[BreiteSeite]

I totally agree that ZF Api Problem should not interpret exception codes as http status codes. Exception codes can mean anything. For example, \PDOException uses code to transport the SQLSTATE error code.

I therefore propose that we extend ProblemExceptionInterface with a new method getHttpStatusCode() which returns an integer value to use. Otherwise we just assume 500.

@weierophinney could you please give feedback? If you want, i could create a pull request.

[weierophinney]

@BreiteSeite makes sense; feel free to start a PR! :)

[FrankGiesecke]

How is the status of this issue or it's pull request? I think it would be very helpful, if the api-problem does not interpret the exception code as http status code.

[leogr]

I think api-problem should interpret the exception code only if the exception implements the ProblemExceptionInterface (like the api-problem DomainException).

Furthermore, IMHO, only codes in 4xx and 5xx ranges should be considered "problems". For example:

throw new \Exception('Error', 302);

will produce a 301 Moved Permanently http status code, but without the Location header. I don't think it makes sense.

For this reason, I had to patch temporary some projects. Currently, I attached a listener to intercept exceptions:

use Zend\Mvc\MvcEvent;
use ZF\ApiProblem\Exception\ProblemExceptionInterface;

class UnhandledExceptionListener
{
    public function __invoke(MvcEvent $e)
    {
        if (!$e->isError()) {
            return;
        }

        $exception = $e->getParam('exception');
        if ($exception
            && !$exception instanceof ProblemExceptionInterface
            && $exception instanceof \Exception
            && ($exception->getCode() < 400 || $exception->getCode() > 599)
        ) {
            $internalServerErrorEx = new InternalServerErrorException($exception);
            $e->setParam('exception', $internalServerErrorEx);
        }
    }
}

class InternalServerErrorException extends \Exception
{
    public function __construct($previous)
    {
        parent::__construct('Internal Server Error', 500, $previous);
    }
}

A possibile solution to avoid BCs in 1.0.x is to check the code ranges only. The $exception instanceof ProblemExceptionInterface could be introduced later. @weierophinney could you give me a feedback about above solutions, please? Then I could create a PR. I think it's a very important issue.

[leogr]

@weierophinney any news?

[weierophinney]

This repository has been closed and moved to laminas-api-tools/api-tools-api-problem; a new issue has been opened at https://github.com/laminas-api-tools/api-tools-api-problem/issues/6.