There are some warnings about directly accessing the request object in this way in
* 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:
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.