proof of concept illuminate http

[SychO9]

I've stopped here where we have successful tests and a mostly working app.

What is left

• adapt uploaded files to use new request api
• fix maintenance handler (has to be done through a middleware now)
• cache routes (haven't tested performance yet)
• fix updater routes and installer routes

Nice to have

• set illuminate request session & actor resolvers

Chores

• remove psr7 middlewares from dependencies

---

Architectural changes Here is a diagram that explains how this changes the base architecture

Review To make it easier reviewing the changes, here is what you should look at and ignore

Ignore: All Tests changes

Focus On: Application, SiteInterface, Server, Middlewares, Controllers, Router, RequestUtil, ExceptionHandler, HandleErrors, UrlGenerator, routes.php files. Service Providers (Forum, Admin, API).

Do we want these changes

The case for no

• The mutable request and binding it to the container is not ideal, for instance, the client has to temporarily bind a new request and rebind the old one after the response is resolved. It could lead to more similar issues.
• This closes us to an ecosystem of PSR-7 standards, while PSR7 Request handlers still work (controllers), other things don't (like psr7 middleware).
• This introduces a lot of breaking changes, primarily related to the use of the new request implementation which propagates to a lot of areas (like tests).
• Whatever features we seek from laravel that requires its request handling, we might just recreate some of it instead.

The case for Yes

• Gets us closer to a more Laravel development experience and could attract more contributors in the future, which we haven't had for a couple years+. (This goes for both core, and ecosystem).
• Makes integrations with the Laravel ecosystem easier.
• ?

[tankerkiller125]

There is a PSR-7 middleware abstraction, but it's not ideal. https://github.com/jshannon63/psr7middleware but that's the only "potential workaround for a NO item".