I was wondering, would it make sense for apigiliy and api-problem in general to support a translator service, so as to translate all messages in the ApiProblem response based on the Accept-Language HTTP header?

This way in theory a multilingual rest client could get different error messages per language set in the request.

What do you think is the best way to go about it?

Originally posted by @twmobius at zfcampus/zf-api-problem#40

I'm writing an error listener that listens for api problem responses and logs them. I'm generating a unique id for the log entry and would like to attach this to the api problem to be included in the response. It seems the only way to set $additionalDetails is on construct.

Originally posted by @pdizz at zfcampus/zf-api-problem#24

I try to figure out how listeners in ApiProblem works. They attach to different events but every event has different method/code and very similar flow to create ApiProblem. I'm ready to rebuild it, but I would like to be sure it's something wrong in current code.

Originally posted by @snapshotpl at zfcampus/zf-api-problem#30

I use the zf-api-problem, zf-mvc-auth module in combination with apigility. Since I have to ship a regular webapplication also within the project I use the zf-mvc-auth events to handle both api and webapp authentication stuff. Everything works quite nice on the apigility side.

However my webapplication is based on session for login/logout. So all protected routes within my webapp are automatically handled by zf-mvc-auth and my listeners that generate everything needed. As soon as I try to access a protected resource a 403 Error is created which is correct also, but this response is always a application/problem+json, which is obviously correct for the api but incorrect on side of the webapp where I want to have a regular error site. Is there some way to change or configure the way how the problems get rendered?

BR Daniel

Originally posted by @dhofstetter at zfcampus/zf-api-problem#25

Assume displayExceptions is true.

If in the exception stack trace a function argument contains binary data that json_encode could not handle, then json_encode will return false. As a result the response content is empty.

This happens at following lines:
RenderErrorListener.php#L94
ApiProblemResponse.php#L59

This situation can occur in various debugging scenarios, e.g. uploading a file and passing its blob to a function, and it can be pretty difficult to overcome because the empty response.

Proposed solution
A better choice would be to use \Zend\Json\Encoder::encode because it can correctly handle the encoding of binary data that json_encode can not encode.

// Assuming $data['blob'] contains the binary data of a PDF file

json_encode($data); // return false

\Zend\Json\Json::encode($data); // return false if the json extension is available, otherwise \Zend\Json\Encoder::encode is used

\Zend\Json\Encoder::encode($data); // return the encoded json

Originally posted by @leogr at zfcampus/zf-api-problem#29

I have noticed, that SendApiProblemResponseListener is modifying the response content AFTER sending headers (if display_exceptions is enabled).

I have a Content-Length header based on response content but this header is now responding a wrong length as it doesn't know if the content gets modified afterwords.

On the same time I'm automatically pretty printing the response if the request contains header X-Pretty: 1 but this will also be ignored as the content gets rewritten in this case.

What is the reason to overwrite HttpResponseSender instead of listening on EVENT_FINISH?

This is my broken code:

class Module
{
    public function onBootstrap(MvcEvent $e)
    {
        $eventManager  = $e->getApplication()->getEventManager();
        $eventManager->attach(MvcEvent::EVENT_FINISH, [$this, 'onFinish'], -1000);
    }

    public function onFinish(MvcEvent $event)
    {
        $response = $event->getResponse();
        $request  = $event->getRequest();

        if ($request instanceof HttpRequest && $response instanceof HttpResponse && !($response instanceof HttpStreamResponse)) {
            $rqHeaders = $request->getHeaders();
            $rsHeaders = $response->getHeaders();
            $rsContent = $response->getContent();

            // pretty print JSON response
            if ($rqHeaders->has('X-Pretty')
                && $rqHeaders->get('X-Pretty')->getFieldValue() === '1'
                && is_string($rsContent) && $rsContent
                && $rsHeaders->has('Content-Type')
                && preg_match('/^application\\/(.*\\-)?json/', $rsHeaders->get('Content-Type')->getFieldValue())
            ) {
                $rsContentDecode = json_decode($rsContent);
                if ($rsContentDecode !== null) {
                    $prettyOptions = JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE;
                    $rsContent     = json_encode($rsContentDecode, $prettyOptions);
                    $response->setContent($rsContent);

                    if ($rsHeaders->has('Content-Length')) {
                        $rsHeaders->removeHeader($rsHeaders->get('Content-Length'));
                    }
                    $rsHeaders->addHeaderLine('Content-Length', strlen($rsContent));
                }
            }

            // Send Content-Length header if possible
            if (is_string($rsContent) && !$rsHeaders->has('Content-Length')) {
                $rsHeaders->addHeaderLine('Content-Length', strlen($rsContent));
            }
        }
    }
}

Originally posted by @marc-mabe at zfcampus/zf-api-problem#54

API Problem response with HTTP status code from exception when it's valid rage of HTTP codes. But what about situation when some library throws own exceptions, with own codes (example 302, and it means that user doesn't exist)? It does't make sense.
My solution for this is to use code from exceptions only when exception implements \ZF\ApiProblem\Exception\ExceptionInterface

Originally posted by @snapshotpl at zfcampus/zf-api-problem#26

This package and some other api-tools packages using laminas/laminas-zendframework-bridge which is abandoned.
laminas/laminas-zendframework-bridge should be removed.

Bug Report

See https://github.com/laminas-api-tools/api-tools-api-problem/actions/runs/1558155992

We'll need to do some manual steps:

• create 1.6.x
• check release notes
• create 1.6.0 milestone

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 :-)

Originally posted by @snapshotpl at zfcampus/zf-api-problem#27

Switch from Travis-CI to GHA CI workflow, as documented at https://gist.github.com/weierophinney/b003e50c3c2667d08076caf31ebd36a4

In your current code ApiProblemResponse class have this constructor

public function __construct(ApiProblem $apiProblem)
    {
        $this->apiProblem = $apiProblem;
        $this->setCustomStatusCode($apiProblem->status);
        $this->setReasonPhrase($apiProblem->title);
        $this->jsonFlags = JSON_UNESCAPED_SLASHES | JSON_PARTIAL_OUTPUT_ON_ERROR;
    }

Could you please add one more property in jsonFlags JSON_FORCE_OBJECT

Like this

public function __construct(ApiProblem $apiProblem)
    {
        $this->apiProblem = $apiProblem;
        $this->setCustomStatusCode($apiProblem->status);
        $this->setReasonPhrase($apiProblem->title);
        $this->jsonFlags = JSON_UNESCAPED_SLASHES | JSON_PARTIAL_OUTPUT_ON_ERROR | JSON_FORCE_OBJECT;
    }

This will give api response to send non associated arrays keys for example during validation message generation, when keys are number and not string

like this

array(
3 =>'message1',
5 =>'message2',
7 =>'message3',
)

Originally posted by @developer-devPHP at zfcampus/zf-api-problem#56

Feature Request

Summary

To be prepared for the december release of PHP 8.0, this repository has some additional TODOs to be tested against the new major version.

In order to make this repository compatible, one has to follow these steps:

• Modify composer.json to provide support for PHP 8.0 by adding the constraint ~8.0.0
• Modify composer.json to drop support for PHP less than 7.3
• Modify composer.json to implement phpunit 9.3 which supports PHP 7.3+
• Modify .travis.yml to ignore platform requirements when installing composer dependencies (simply add --ignore-platform-reqs to COMPOSER_ARGS env variable)
• Modify .travis.yml to add PHP 8.0 to the matrix (NOTE: Do not allow failures as PHP 8.0 has a feature freeze since 2020-08-04!)
• Modify source code in case there are incompatibilities with PHP 8.0

Feature Request

Summary

As decided during the Technical-Steering-Committee Meeting on August 3rd, 2020, Laminas wants to implement vimeo/psalm in all packages.

Implementing psalm is quite easy.

Required

• Create a psalm.xml in the project root
• Copy and paste the contents from this psalm.xml.dist
• Run $ composer require --dev vimeo/psalm
• Run $ vendor/bin/psalm --set-baseline=psalm-baseline.xml
• Add a composer script static-analysis with the command psalm --shepherd --stats
• Add a new line to script: in .travis.yml: - if [[ $TEST_COVERAGE == 'true' ]]; then composer static-analysis ; fi
• Remove phpstan from the project (phpstan.neon.dist, .travis.yml entry, composer.json require-dev and scripts)

Optional

• Fix as many psalm errors as possible.