UriConstraints adds VirtualDirectory twice when withPathPrefix() is being used.

[drwatson85]

I'm currently migrating from Flow 4 to 6.3, after upgrading to 5.2 all my generated links contain the VirtualDirectory twice.

Example: I use the FormViewHelper to generate a form. The action attribute then has: "VirtualDirectory/VirtualDirectory/controller/action"

In Neos\Flow\Mvc\Routing\Router::resolve():

$uriConstraints = $route->getResolvedUriConstraints()->withPathPrefix($resolveContext->getUriPathPrefix());
$resolvedUri = $uriConstraints->applyTo($resolveContext->getBaseUri(), $resolveContext->isForceAbsoluteUri());

withPathPrefix already adds the basePath, but in Neos\Flow\Mvc\Routing\Dto\UriConstraints::applyto():

// In case the base URL contains a path segment, prepend this to the URL (to generate proper host-absolute URLs)
if ($baseUri->getPath() !== '' && $baseUri->getPath() !== '/') {
     $uri = $uri->withPath(trim($baseUri->getPath(), '/') . '/' . ltrim($uri->getPath(), '/'));
}

The basePath gets added again. I don't fully understand if and why this is necessary or if it's a bug. Does anyone have more insight?

Currently all my links have the virtual directory twice.

[drwatson85]

Something related was already mentioned in https://github.com/neos/flow-development-collection/pull/1682#issuecomment-549055373 by @kitsunet

[albe]

Thanks a lot for the deep analysis of the issue so far! I see how this must be related to the PR you mentioned and hence #1797. I'm not sure why the revert of the PR in #1841 doesn't prevent the issue though - that would mean there's another thing we're not aware of and we need more analysis to understand the problem fully.

So for starters, by VirtualDirectory you mean a base route that you configured in your webserver, rather than a physical subdirectory of your web root? Optimally we'd have some reproducible minimal setup for the case - or alternatively a failing functional test case that replicates the problem by simulating the environment.

[drwatson85]

Hey, no problem. Excuse the confusion about versions. While trying to write a test case for this i noticed that the mentioned code was introduced in #1804 and only exists from 6.0 onwards.

I added a (currently failing) testcase in #2337 that reproduces my setup and leads to the prefix being added twice.

[kaystrobach]

Will verify your patch tomorrow

[kaystrobach]

Sry, took longer than expected, we are using that patch in production now, works as expected!