Start of the plugin queue

[dbu]

In PHP-HTTP, we have the method signature public function handleRequest(RequestInterface $request, callable $next, callable $first);

Having the first delegate allows to restart the request. We use this for example with a plugin that handles redirect status codes - that plugin can simply restart the queue with a new request.

How would you feel about adding that to PSR-15 as well? I don't know if it makes sense on the server side - one use case i can think of would be a plugin that handles ESI and does the sub requests to resolve the esi fragments. But not sure if that is a good scenario. Maybe just another point for #20, to separate the client middleware from PSR-15

[shadowhand]

Anything that only makes sense in client middleware (or server) should probably be excluded at this point. I don't see this being viable for server dispatchers.

[dbu]

@shadowhand the only use case for server side i could think of was ESI handling as middleware. what do you think of that use case? or would you see a different solution to make this work in middleware?

if this PSR is mostly about generic middleware things and server side, but not client side, i think it would be good if the (meta?) document would explicitly say this to avoid confusion.

[mindplay-dk]

I think that passing $first as part of the middleware interface itself, to account for the eventual rare case such as ESI, is probably unnecessary?

In a case such as ESI, such middleware could simply receive the dispatcher itself, e.g. via constructor injection, ahead of time, and dispatch that internally.

Granted, interoperability in that case wouldn't be covered by this PSR, which makes me wonder again if we ought to have a Dispatchable interface - an idea that was previously rejected - e.g.:

interface Dispatchable {
    public function dispatch(RequestInterface $request): ResponseInterface;
}

However, as noted in that thread, such as interface seems orthogonal to this standard, as it's extremely general and not at all middleware-specific - it would require a dedicated (though humble) PSR, I think.

If such an interface were standardized at a later time, that would cover this use-case, I think? If so, this is likely not an immediately requirement that blocks us from moving forward with this PSR.

[dbu]

i agree that including a dispatchable interface into this PSR would be out of scope.

the middleware in that case would need a setter injection i think. or the middleware stack would need setters - if both only use constructor injection, you get a chicken-and-egg problem. but i agree that its an edge case, plus if the actual entry point is not the stack of middleware but some other client, having $first is actually misleading.