There are some warnings about directly accessing the request object in this way in \Drupal::request
:
* Note: The use of this wrapper in particular is especially discouraged. Most
* code should not need to access the request directly. Doing so means it
* will only function when handling an HTTP request, and will require special
* modification or wrapping when run from a command line tool, from certain
* queue processors, or from automated tests.
*
* If code must access the request, it is considerably better to register
* an object with the Service Container and give it a setRequest() method
* that is configured to run when the service is created. That way, the
* correct request object can always be provided by the container and the
* service can still be unit tested.
Any form controller extending \Drupal\Core\Form\FormBase
automatically has this dependency injected, and it may be accessed using:
$this->getRequest()->getSchemeAndHttpHost()
I think (but haven't tested) that a regular page controller extending \Drupal\Core\Controller\ControllerBase
could provide the request_stack
service by overriding the \Drupal\Core\Controller\ControllerBase::create
function, and then setting a $request
property in the constructor. This is described really well for forms, and the same process should apply for page controllers: https://www.drupal.org/docs/8/api/services-and-dependency-injection/dependency-injection-for-a-form.