Http Middleware Laravel Package

Getting Started

This package defines the original PSR-15 middleware interfaces (MiddlewareInterface, RequestHandlerInterface)—but it is archived and superseded by the official psr/http-server-middleware package. In Laravel, you should not install or use this package directly. Instead:

• For Laravel ≥ v6, PSR-15 compatibility is built-in via the psr/http-server package (via illuminate/http), so your custom middleware already conforms to the standard without extra dependencies.
• If maintaining an old Laravel app that explicitly depends on this package (e.g., via http-interop/http-middleware in composer.json), upgrade to the official PSR-15 implementation first. Start by running composer require psr/http-server-middleware and audit middleware implementations for interface compatibility.
• First use case: Inspect your existing middleware classes—do they implement process()? Modern PSR-15 uses __invoke() or handle(), so legacy middleware will need refactoring.

Implementation Patterns

• Laravel middleware never requires this package—your app/Http/Middleware classes work out of the box because Laravel implements the PSR-15 contract internally (via MiddlewarePipe or route middleware stacks).
• In custom middleware runners (not Laravel), you might define a pipeline like:

  $middleware = [
      new AuthMiddleware(),
      new LocaleMiddleware(),
      new RequestHandler(), // Implements RequestHandlerInterface
  ];
  // Manual execution (avoid in Laravel—use framework pipelines instead)
  $request = $request ?? $serverRequest; // PSR-7/15 request
  $response = array_reduce($middleware, function ($response, $middleware) {
      return $middleware->process($request, $responseHandler ?? $this); // ⚠️ deprecated signature
  }, $initialResponse ?? null);
  

• Critical Laravel-specific guidance: Never add http-interop/http-middleware as a dependency in new Laravel projects. When writing tests, your lluminate\Http\Request and Response objects are PSR-7/15 compatible when needed (via Laravel’s toPsrResponse() / fromPsrRequest() helpers), but you don’t need this package to make that work.
• Use Laravel’s Middleware::pipe() or custom Pipeline classes for composition—they follow PSR-15 semantics without requiring the archived interfaces.

Gotchas and Tips

• Archived = abandonware: This package has no PHP 8+ support and conflicts with psr/http-server-middleware. If Composer resolves both, you’ll see ClassAlreadyExists errors (e.g., duplicate MiddlewareInterface). Run composer why http-interop/http-middleware to audit legacy usage.
• Laravel’s PSR-15 is implicit: Your middleware already adheres to PSR-15 semantics (e.g., $next($request) passes the request to the next handler), but Laravel uses its own method (__invoke or handle) instead of process(). You don’t need to implement MiddlewareInterface.
• Interface mismatch trap: If you migrate middleware from this package to modern Laravel, process(ServerRequestInterface $req, RequestHandlerInterface $handler) must be rewritten as __invoke(Request $req, Closure $next). The RequestHandlerInterface becomes the Closure $next—a conceptual shift, not a breaking change.
• Discovery pitfalls: Tools like php-http/discovery may fail to locate PSR-15 implementations because this package’s interfaces are deprecated. Always declare concrete types in Laravel: type-hint Request, Response, and use Closure $next.
• When debugging: If middleware isn’t running, check app/Http/Kernel.php—your middleware stack is there. This package plays no role. Its interfaces are only relevant if you manually wrote new HttpInteropMiddleware(...) somewhere in legacy code (strong smell of technical debt).