As already mentioned in #190, there is a naming conflict in the ErrorHandler.

I had some feedback of trainees which asked me, why the ErrorHandler ain't a RequestHandler, as its name says. That made me think about the naming and I realized, its just because of the missing Middleware postfix.

However, I'd like to rename the ErrorHandler to ErrorHandlerMiddleware to avoid future confusions about where the difference between RequestHandlerInterface and MiddlewareInterface is.

Originally posted by @boesing at https://github.com/zendframework/zend-stratigility/pull/191

| Q | A |-------------- | ------ | Documentation | yes | Bugfix | no | BC Break | no | New Feature | no | RFC | no | QA | no

Description

The docs folder contains several manual redirects, i.d. HTML documents with a hard-coded redirect for legacy URLs. With the adoption of the MkDocs redirect plugin there is a simpler solution available.

This PR moves the redirects for legacy URLs in mkdocs.yml and removes the manually created HTML documents from Git.

Should fix #14

Tests are difficult, or even impossible, to provide for this. PDOException is allowed to return strings from getCode(), but PHP makes it difficult or impossible for mere mortals to do the same.

Someone more involved should probably review this thoughtfully before merging.

| Q | A |-------------- | ------ | Documentation | no | Bugfix | yes | BC Break | no | New Feature | no | RFC | no | QA | no

Description

Fixes #14.

This re-opens zendframework/zend-stratigility#191 and handles #2

Summary

As already mentioned in zendframework/zend-stratigility#190 (migrated to #3), there is a naming conflict in the ErrorHandler.

I had some feedback of trainees which asked me, why the ErrorHandler ain't a RequestHandler, as its name says. That made me think about the naming and I realized, its just because of the missing Middleware postfix.

However, I'd like to rename the ErrorHandler to ErrorHandlerMiddleware to avoid future confusions about where the difference between RequestHandlerInterface and MiddlewareInterface is.

Maybe same procedure as in #191

As the NotFoundHandler is technically a RequestHandler, I am moving it to the Handler namespace instead while marking the NotFoundHandler in the Middleware namespace as deprecated.

Originally posted by @boesing at https://github.com/zendframework/zend-stratigility/pull/192

This PR contains the following updates:

| Package | Type | Update | Change | |---|---|---|---| | vimeo/psalm | require-dev | major | ^4.29.0 -> ^5.0.0 |

Release Notes

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

• [ ] If you want to rebase/retry this PR, check this box

Read more information about the use of Renovate Bot within Laminas.

Signed-off-by: Abdul Malik Ikhsan [email protected]

| Q | A |-------------- | ------ | QA | yes

Description

Since composer.json require php 7.4, php 7.4 syntax can be applied with typed properties.

• For final class, typed properties for protected is allowed if no inherit of parent or used by its final class parent.
• Otherwise, update only private properties.

• Bumps dependencies to recent versions
• Removes support for 7.3
• Drops Doc Header Tooling and config
• Solves some newly discovered psalm issues and baselines others
• Fixes linting issues with markdown files
• Clean up tool configuration files and export ignores

| Q | A |-------------- | ------ | QA | yes

Description

This should help to get #26 merged

| Q | A |-------------- | ------ | QA | yes

Description

This PR removes the usage of phpspec/prophecy and also dropped a unit test which does not make sense.

[QA]

• Normalize composer.json and/or update composer.lock
  • Restructure composer.json according to the underlying JSON schema.
  • Prevent inconsistencies between all (200+) repositories across all 3 GitHub organizations (laminas, mezzio, and laminas-api-tools).

Bug Report

| Q | A |------------ | ------ | Version(s) | Any since 3.0alpha1

Summary

Utils::getStatusCode() incorrectly assumes that the code value returned from $error->getCode() will be an integer.

If you only look at Throwable that would seem correct. However, both Error and Exception define getCode(): mixed.

In the wild, PDOException can return a string code. For example, if PDO encounters a missing table, it will throw with a message of "SQLSTATE[42S02]: Base table or view not found: 1146 Table 'db.table_name' doesn't exist" and a code of '42S02'. The string then forces the literal 400 and 600 to be coerced to strings in the expression on line 33, which causes the expression to evaluate to true.

The method then attempts to return $errorCode (which is a string), which violates the return type declaration. Kaboom.

Current behavior

getStatusCode() throws with a message of Laminas\Stratigility\Utils::getStatusCode(): Return value must be of type int, string returned

How to reproduce

Throw an exception where getCode() returns a string starting with '4' or '5' followed by at least one letter.

Expected behavior

Not entirely sure. I certainly don't expect it to throw. I'm not sure how the method is used elsewhere.

Unfortunately, it's part of stratigility's public API. For instance, it's used in three classes in mezzio.

I suspect the intended behavior is that non-integer codes from the $error->getCode() should result in the conditional evaluating false. If that's right, then prepending is_int($errorCode) && to the expression in the if statement on line 33 ought to do it.

| Q | A |-------------- | ------ | New Feature | yes

Description

• Resolve #25

Added

• [BC] PSR-17 Support

Changed

• [BC] The parameter $responseFactory of Laminas\Stratigility\Handler\NotFoundHandler#__construct() changed from callable to a non-contravariant Psr\Http\Message\ResponseFactoryInterface
• [BC] The parameter $responseFactory of Laminas\Stratigility\Middleware\ErrorHandler#__construct() changed from callable to a non-contravariant Psr\Http\Message\ResponseFactoryInterface
• [BC] The parameter $responseFactory of Laminas\Stratigility\Middleware\ErrorHandler#__construct() changed from callable to Psr\Http\Message\ResponseFactoryInterface

Removed

• [BC] Class Laminas\Stratigility\Middleware\NotFoundHandler has been deleted
• [BC] Function Zend\Stratigility::doublePassMiddleware has been deleted
• [BC] Function Zend\Stratigility::host has been deleted
• [BC] Function Zend\Stratigility::middleware has been deleted
• [BC] Function Zend\Stratigility::path has been deleted

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

Awaiting Schedule

These updates are awaiting their schedule. Click on a checkbox to get an update now.

• [ ] Lock file maintenance

Detected dependencies

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

Feature Request

| Q | A |------------ | ------ | New Feature | yes | RFC | yes | BC Break | no

Summary

Provide support for using PSR-17 response factories instead of a callable for generating error and not found responses. See mezzio/mezzio#81 for details.

• [x] I was not able to find an open or closed issue matching what I'm seeing.
• [x] This is not a question.

I was taking a look to the PathMiddlewareDecorator for a project I'm working on, but it kinda didn't suited my needs.

• I needed it to match a routes flexibly using regular expressions if necessary.
• I needed it to match optionally by request route
• I needed to decide if the middleware being decorated was going to execute if the routed matched or didn't match.

So I ended up building my own decorator. How keen are you guys of accepting a PR with it? Here's a very naive implementation:

use Psr\Http\Message\ResponseInterface as Response;
use Psr\Http\Message\ServerRequestInterface as Request;
use Psr\Http\Server\MiddlewareInterface;
use Psr\Http\Server\RequestHandlerInterface as NextHandler;

/**
 * Decorates a middleware to be executed on a router pattern match/un-match
 *
 * You can optionally pass a method to the arguments.
 *
 * @author Matías Navarro Carter <[email protected]>
 */
final class PathMiddlewareDecorator implements MiddlewareInterface
{
    public const IF_MATCHES = 1;
    public const IF_NOT_MATCHES = 0;

    /**
     * @var MiddlewareInterface
     */
    private $middleware;
    /**
     * @var int
     */
    private $executionRule;
    /**
     * @var string|string[]
     */
    private $path;
    /**
     * @var string|null
     */
    private $method;

    /**
     * PathMiddlewareDecorator constructor.
     *
     * @param MiddlewareInterface $middleware The middleware to execute.
     * @param string|string[]     $path A path pattern or an array of patterns.
     * @param string|null         $method A method to match.
     * @param int                 $executionRule The rule of execution.
     */
    public function __construct(
        MiddlewareInterface $middleware,
        $path,
        string $method = null,
        int $executionRule = self::IF_MATCHES
    ) {
        $this->middleware = $middleware;
        $this->path = $path;
        $this->method = $method;
        $this->executionRule = $executionRule;
    }

    /**
     * @param Request     $request
     * @param NextHandler $handler
     *
     * @return Response
     */
    public function process(Request $request, NextHandler $handler): Response
    {
        $match = $this->matches($request);

        if (self::IF_MATCHES === $this->executionRule && true === $match) {
            return $this->middleware->process($request, $handler);
        }
        if (self::IF_NOT_MATCHES === $this->executionRule && false === $match) {
            return $this->middleware->process($request, $handler);
        }

        return $handler->handle($request);
    }

    /**
     * @param Request $request
     *
     * @return bool
     */
    private function matches(Request $request): bool
    {
        if ($this->method && $request->getMethod() !== $this->method) {
            return false;
        }

        return $this->matchesRegex($request->getUri()->getPath(), $this->path);
    }

    /**
     * @param string $requestPath
     * @param        $pathOrPaths
     *
     * @return bool
     */
    private function matchesRegex(string $requestPath, $pathOrPaths): bool
    {
        if (is_array($pathOrPaths)) {
            foreach ($pathOrPaths as $string) {
                $result = $this->matchesRegex($requestPath, $string);
                if (true === $result) {
                    return true;
                }
            }
        }
        if (\is_string($pathOrPaths)) {
            return 0 !== preg_match('/'.str_replace('/', '\/', $pathOrPaths).'/', $requestPath);
        }

        return false;
    }
}

Of course it should be named differently to the one you guys already have. Maybe ConfigurablePathMiddlewareDecorator?

Originally posted by @mnavarrocarter at https://github.com/zendframework/zend-stratigility/issues/183

Next handler in the pipeline passed as a second parameter to the middleware is not safe to invoke multiple times. What actually Next handler is is defined at runtime and is not guaranteed to be stateless, which can lead to undefined behavior.

For example, middleware designed to invoke Next handler second time will cause unintented side effects if Fail2Ban middleware is then registered next in the pipeline.

If handler needs to be invoked multiple times, it should be selected explicitly and injected as a direct dependency (directly or lazy way or as a proxy to a middleware pipe elsewhere, etc).

Originally posted by @Xerkus at https://github.com/zendframework/zend-stratigility/issues/187

Fixed a typo in $handler invocation in the documentation for creating-middleware.md

• [ ] Are you fixing a bug?

  • [ ] Detail how the bug is invoked currently.
  • [ ] Detail the original, incorrect behavior.
  • [ ] Detail the new, expected behavior.
  • [ ] Base your feature on the master branch, and submit against that branch.
  • [ ] Add a regression test that demonstrates the bug, and proves the fix.
  • [ ] Add a CHANGELOG.md entry for the fix.

• [ ] Are you creating a new feature?

  • [ ] Why is the new feature needed? What purpose does it serve?
  • [ ] How will users use the new feature?
  • [ ] Base your feature on the develop branch, and submit against that branch.
  • [ ] Add only one feature per pull request; split multiple features over multiple pull requests
  • [ ] Add tests for the new feature.
  • [ ] Add documentation for the new feature.
  • [ ] Add a CHANGELOG.md entry for the new feature.

• [ ] Is this related to quality assurance?

• [x] Is this related to documentation?

Originally posted by @tworzenieweb at https://github.com/zendframework/zend-stratigility/pull/188