@vudaltsov could you please show a small before/after example ... and maybe also briefly list the changes that existing apps may need to do. Thanks.

@javiereguiluz , sure.

final class UserApiNormalizer implements NormalizerInterface
{
    private $absoluteUrlGenerator;

    public function __construct(AbsoluteUrlGeneratorInterface $absoluteUrlGenerator)
    {
        $this->absoluteUrlGenerator = $absoluteUrlGenerator;
    }

    public function normalize($user, $format = null, array $context = [])
    {
        return [
            // ...
            'avatar' => $this->absoluteUrlGenerator->generateAbsoluteUrl($user->avatar()->path()),
            // ...
        ];
    }

    // ...
}

No changes needed for existing apps. Everything will continue to work as is. But two useful helping services will appear.

AbsoluteUrlGeneratorInterface looks like a routing concern.. probably caused by the "generate" term. Im a bit skeptical about introducing these interfaces under these names. Do we want/need the contracts even?

Maybe RequestContext::toAbsolute/RelativeUrl()?

naming them UrlGenerator will indeed create confusion with the routing component

Agree, I will consider different naming today.

@ro0NL , RequestContext is not aware of the RequestStack, so it's not gonna work. This helper uses them both to get maximum information to generate an absolute url.

As I explained, I created contracts because you might need to decorate these services once you have some additional context for generating an absolute url.

My idea was RequestContext::toAbsoluteUrl(Request $request = null). From a controller pov you have the request at hand.

decorate these services once you have some additional context for generating an absolute url

is this a feature we want to sell? URL composition is a fixed concept IMHO.

@ro0NL , I understand the idea of passing Request as an argument. We'll be able to generate paths for any request then.

The problem is that DX is worse since almost always I will have to inject two services instead of one (+RequestStack) into non request aware services. Also I don't think it is a responsibility of the RequestContext to do this — it's just keeping and providing request data. And I also doubt that I will ever need this in controllers. Mostly in other services, used by commands and message handlers as well (see normalizer example above).

Refactored to UrlHelper without interfaces. Looks better? I don't really like the word helper, honestly...

Why is it final without an interface? Mocking this in userland will be a pain due to its dependencies and internal behavior. If it's something developers shouldn't use, I'd expect it to be @internal.

one could pass a request stack with mocked requests, and any requestcontext. Im not sure utilities need interfaces.

That creates a massive overhead of objects that you have to bring into the correct state in order to test your function, while their internal behavior is of no concern to your particular test if mocking would be sufficient.

what about putting the interface in symfony/contracts? It's a bit weird for HttpFoundation (a specific concept) to introduce a polymorphic matter.

I would not create new abstraction for that. Best would be to add that to the Request class instead.

@fabpot, this cannot be done in Request because we need RequestContext as a fallback. The idea of these helper utilities is to provide absolute urls even outside the request scope (commands, for example).

After discussing with @fabpot , moved to Routing, since the helper depends on the RequestContext which is a routing class.

Btw, what's the best way to handle deprecations in HttpFoundationExtension?
Add @expectedDeprecation?

@fabpot , looked for places in Symfony where I could replace some code with a helper call (except the Twig HttpFoundationExtension). Two looked relevant:

1. symfony/src/Symfony/Component/Security/Http/HttpUtils.php

   Line 65 in 5fe3701

   if (null !== $this->secureDomainRegexp && 'https' === $this->urlMatcher->getContext()->getScheme() && preg_match('#^https?:[/\\\\]{2,}+[^/]++#i', $path, $host) && !preg_match(sprintf($this->secureDomainRegexp, preg_quote($request->getHttpHost())), $host[0])) {

   .

2. symfony/src/Symfony/Bundle/FrameworkBundle/Controller/RedirectController.php

   Line 131 in 5fe3701

   $port = '';

But it seems that UrlHelper will not really help there :)

The latest Travis build: https://travis-ci.org/symfony/symfony/builds/516563856

@xabbuh , done!

Ready!

Thank you @vudaltsov.

Very nice feature Valentin 💥
Would you mind creating a docs PR please? 🙏