HTTP middleware support #179
Description
Activity
Could I propose to delay this post 0.8, potentially 0.9? php-pm is really anxious about getting our hand on 0.8 and anything that could cause a delay would be nice to postpone.
It's also not mentioned in the roadmap right now.
Sounds good to me 👍
@andig I agree that this ticket should not block the request body parsers at all 👍
It's my understanding that the middleware support could easily be used to build request body parsers on top similar to this:
$app = function (function ServerRequestInterface $request) { return Response(200, array(), var_export($request->getParsedBody(), true)); }; $chain = new MiddlewareChain( new BufferMiddleware(1024 * 100), // buffer 100 KiB max new ParseBodyMiddleware(), // simply parse the buffered body $app // execute the actual request handler ); $server = new Server($chain);This is just a very rough draft and we will likely want to implement some API sugar on top of this. This is a very common feature request and probably not something we want every user to type out.
The nice thing about this is that this does not involve a BC break and we can also release this as part of
v0.7.xin the future and subsequently add more parsers in the future.I've prepared a number of PRs for this already and will look into this the upcoming weeks. Also, I'm really curious what @WyriHaximus will come up with 👍
I've prepared a number of PRs for this already and will look into this the upcoming weeks. Also, I'm really curious what @WyriHaximus will come up with 👍
Looking forward to what you have come up with @clue, are you following the middleware PSR discussions in the FIG? Would be most interesting support that when it comes out.
With regards to body parsers I think the parsers them self are in pretty good shape but need some tweaking. Going to get issues with my plans and PR's implementing up starting tomorrow
There is currently no standard of HTTP middleware in PHP, but I consider to use similar approach as the proposed standard of php-fig.