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".

[luceos]

@SychO9 I am assuming this is off the table for now and when we revisit this, it needs to be based off of 2.x anyway? If so, can we close this, the branch can probably be left archived.