• I was not able to find an open or closed issue matching what I'm seeing.
• This is not a question. (Questions should be asked on slack (Signup for Slack here) or our forums.)

Currently, when the ProblemDetailsResponseFactory::createResponse method is called without a type, it tries to infer it from the status, generating values like https://httpstatus.es/404 or https://httpstatus.es/500.

This mainly happens when the ProblemDetailsNotFoundHandler is hit, or the ProblemDetailsMiddleware catches an exception not implementing ProblemDetailsExceptionInterface.

If your API has a specific pattern when generating the types for other errors, it's a bit inconsistent that these two errors follow a different pattern.

It would be nice to be able to define a config map where you set the default type to be used for "every" status code when a value for type was not provided. Something like this:

<?php

return [

    'zend_problem_details' => [
        'default_type_fallbacks' => [
            404 => '/my-app/errors/resource-not-found',
            500 => '/my-app/errors/unknown',
        ],
    ],

];

Then, by injecting this map in the ProblemDetailsResponseFactory, the createTypeFromStatus method could be refactored to look like this:

private function createTypeFromStatus(int $status) : string
{
    return $this->defaultTypeFallbacks[$status] ?? sprintf('https://httpstatus.es/%s', $status);
}

So it would continue working the same when the config map is not defined, but every user would have control over the values generated for the type.

I'm open to implement this if you think it's useful.

Originally posted by @acelaya at zendframework/zend-problem-details#50

Feature Request

Summary

I've seen many other mezzio and laminas components have been updated to support PHP 8.3

I can add support for this one if needed.

Bug Report

Summary

ProblemDetailsMiddleware::attachListener does also allow object&callable

Current behavior

Argument 1 of Mezzio\ProblemDetails\ProblemDetailsMiddleware::attachListener expects callable(Throwable, Psr\Http\Message\RequestInterface, Psr\Http\Message\ResponseInterface):void, but parent type Application\ProblemDetails\NonProblemResponseListener provided

How to reproduce

use Mezzio\ProblemDetails\Exception\ProblemDetailsExceptionInterface;
use Psr\Http\Message\ResponseInterface;
use Psr\Http\Message\ServerRequestInterface;
use Throwable;

final class Foo
{
   public function __invoke(Throwable $error, ServerRequestInterface $request, ResponseInterface $response): void
   {}
}

/** @var Mezzio\ProblemDetails\ProblemDetailsMiddleware $middleware */
$middleware = null;
$middleware->attachListener(new Foo());

Expected behavior

No psalm error.

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

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.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Repository problems

These problems occurred while renovating this repository. View logs.

• WARN: Use matchDepNames instead of matchPackageNames

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update dependency psalm/plugin-phpunit to ^0.19.0
• Update dependency phpunit/phpunit to v11
• Lock file maintenance
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Feature Request

Summary

The ProblemDetailsExceptionInterface does not extend Throwable and thus, it cannot be used as a return type for throws.

This doesn't matter unless you are using static code analysers.

I want to propose extending the Throwable interface for the ProblemDetailsExceptionInterface as in most cases, this might be the use case anyway.

On PHP 8.0.0 an error is thrown. this is due to match becoming a reserved name this has been fixed bu the dependency author willdurand/negotiation. this composer JSON needs to reflect this to bump the version to ^3.0

Summary

In PHP 8.0.0 throws an unexpected error message

Current behavior

An unexpected error occurred; stack trace:

ParseError raised in file /home/cms/vendor/willdurand/negotiation/src/Negotiation/Negotiator.php line 41:
Message: syntax error, unexpected token "match"
Stack Trace:

#0 /home/cms/vendor/composer/ClassLoader.php(322): Composer\Autoload\includeFile('/home/cms/vendo...')
#1 /home/cms/vendor/mezzio/mezzio-problem-details/src/ProblemDetailsMiddleware.php(102):
Composer\Autoload\ClassLoader->loadClass('Negotiation\\Neg...')
#2 /home/cms/vendor/mezzio/mezzio-problem-details/src/ProblemDetailsMiddleware.php(54):
Mezzio\ProblemDetails\ProblemDetailsMiddleware->canActAsErrorHandler(Object(Laminas\Diactoros\ServerRequest))
#3 /home/cms/vendor/mezzio/mezzio/src/Middleware/LazyLoadingMiddleware.php(47):
Mezzio\ProblemDetails\ProblemDetailsMiddleware->process(Object(Laminas\Diactoros\ServerRequest),
Object(Laminas\Stratigility\Next))
#4 /home/cms/vendor/laminas/laminas-stratigility/src/Next.php(61):
Mezzio\Middleware\LazyLoadingMiddleware->process(Object(Laminas\Diactoros\ServerRequest),
Object(Laminas\Stratigility\Next))
#5 /home/cms/vendor/laminas/laminas-stratigility/src/Middleware/ErrorHandler.php(144):
Laminas\Stratigility\Next->handle(Object(Laminas\Diactoros\ServerRequest))
#6 /home/cms/vendor/mezzio/mezzio/src/Middleware/LazyLoadingMiddleware.php(47):
Laminas\Stratigility\Middleware\ErrorHandler->process(Object(Laminas\Diactoros\ServerRequest),
Object(Laminas\Stratigility\Next))
#7 /home/cms/vendor/laminas/laminas-stratigility/src/Next.php(61):
Mezzio\Middleware\LazyLoadingMiddleware->process(Object(Laminas\Diactoros\ServerRequest),
Object(Laminas\Stratigility\Next))
#8 /home/cms/vendor/laminas/laminas-stratigility/src/MiddlewarePipe.php(84):
Laminas\Stratigility\Next->handle(Object(Laminas\Diactoros\ServerRequest))
#9 /home/cms/vendor/laminas/laminas-stratigility/src/MiddlewarePipe.php(73):
Laminas\Stratigility\MiddlewarePipe->process(Object(Laminas\Diactoros\ServerRequest),
Object(Laminas\Stratigility\EmptyPipelineHandler))
#10 /home/cms/vendor/laminas/laminas-httphandlerrunner/src/RequestHandlerRunner.php(96):
Laminas\Stratigility\MiddlewarePipe->handle(Object(Laminas\Diactoros\ServerRequest))
#11 /home/cms/vendor/mezzio/mezzio/src/Application.php(82): Laminas\HttpHandlerRunner\RequestHandlerRunner->run()
#12 /home/cms/public/index.php(28): Mezzio\Application->run()
#13 /home/cms/public/index.php(29): {closure}()
#14 {main}

How to reproduce

run on PHP 8.0.0

Expected behavior

no error message

• I was not able to find an open or closed issue matching what I'm seeing.
• This is not a question. (Questions should be asked on slack (Signup for Slack here) or our forums.)

I have run into this use case:

My application has a JSON API which is served under the /rest path, but also 3 or 4 more routes which are not part of this API context.

For the API I use "problem details" for the errors, but I also have some other error handling logic for the other routes.

Because of this, my middleware pipeline looks more or less like this:

// ...

$app->pipe(Zend\Stratigility\Middleware\ErrorHandler::class);
$app->pipe('/rest', Zend\ProblemDetails\ProblemDetailsMiddleware::class);

// More middlewares...

$app->pipe('/rest', Zend\ProblemDetails\ProblemDetailsNotFoundHandler::class);
$app->pipe(App\NotFoundHandler::class);

With this approach, most of the use cases work as expected, except when a request is performed to a not-found path which starts with /rest, proividing a non-JSON Accept header, but one that matches *+xml.

This usually happens when a request is performed from a browser, in which case the Accept has the value text/html,application/xhtml+xml,application/xml...

This is making the ProblemDetailsNotFoundHandler to generate an xml response, but I would expect/like it to be skipped and my custom NotFoundHandler (the second one) to be executed instead.

Proposal

In order to "solve" this, the first thing that comes to my mind is this approach:

Allowing to dynamically determine which "contexts" should be enabled for the module, as in "JSON only", "XML only" or "both".

I see that currently, the headers that determine if the ProblemDetailsMiddleware and the ProblemDetailsNotFoundHandler should act as error handlers, are hardcoded on ProblemDetailsResponseFactory::NEGOTIATION_PRIORITIES.

Since the three classes make use of that constant to call a Negotiator instance, maybe the whole logic could be wrapped into a helper which is injected in the three of them.

This helper could then get the "context" configuration or fallback to "both", keeping current behavior.

Let me know if you think this makes sense, or if you think there's any simpler way to achieve the same result.

In any case, I'm open to contribute a PR with the required changes.

Originally posted by @acelaya at zendframework/zend-problem-details#49

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

With mezzio/mezzio#75, a PoC was merged to mezzio to show how forward compatibility to PSR-17 could be added without having a BC break.

This package uses the callable response factory as well and can adapt the same logic as implemented in mezzio/mezzio v3.5.0.