RFC: Avoid HTTPApplication for CLI

[sminnee]

HTTPApplication is a system for processing URLs in a webserver environment.

In a CLI context, it only introduces distractions.

For CLI requests, we should generate a CoreKernel object but handle BuildTasks and database building without using SilverStripe/Control. This would probably be a good time to create it as a Symfony console tool, perhaps incorporating one of the existing tools in this space as opposed to reinventing the wheel.

A special "run URL" option could be used for those cases when do do actually want a URL, but it should be the exception rather than the rule.

I'd recommend this as a 4.1 change that preserves the existing behaviour as deprecated.

Note that the implication of this is that no HTTPMiddlewares would ever get run in CLI mode, which simplifies things such as #7492.

[tractorcow]

Could it even be a separate tool, silverstripe/console perhaps?

[tractorcow]

Note that the implication of this is that no HTTPMiddlewares would ever get run in CLI mode, which simplifies things such as #7492.

This sounds about right to me!

[tractorcow]

One thing to consider is what "simulated web-requests" would do. One example I can think of is rendering the error page template into assets/error-404.html. Perhaps we just don't do that anymore, thus eliminating that need?

[sminnee]

One thing to consider is what "simulated web-requests" would do. One example I can think of is rendering the error page template into assets/error-404.html. Perhaps we just don't do that anymore, thus eliminating that need?

It's a good question, I'd probably leave it separate from this issue. I think we need to look at how middlewares are typically used before deciding whether they should be included in the default render of a staticpublisher page or a 404 error page. My guess is that it's better to exclude them by default, as they are typically used to handle log-in, session, redirection, flush, header mangling, request blocking, none of which apply in such a case.

The error page generator and staticpublisher could probably each have an extension hook where middlewares specific to those use cases could be attached, which by default would be empty.

[chillu]

This is rearing its ugly head again in a new use case: We want to generate the GraphQL schema during release packaging, which often happens in environments separate from the actual webserver (e.g. AWS CodeBuild or CircleCI). This happens through sake, but that kicks off all kinds of wrong assumptions about the state of the environment: Validate database credentials, execute middleware that relies on database queries, trigger HTTPOutputHandler to show errors. Its a good test case for our kernel architecture, but a bit of a rabbit hole.

[GuySartorelli]

Closing as this will be done as part of #11341
The new sake will by default not use HTTPApplication nor HTTPRequest, though there is a sake navigate command that will essentially do what old sake did, for those who have a need to do that for whatever dark magic they're doing.