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.