This issue is not specific to the HTTP protocol, but also with SSH a wrong hostname will be used in the chang URL.

I've spent a few hours trying to understand what's going on and try to fix this. The root cause seems to be the fact that parts of the receive commits command are done on a different thread, and the fact that the virutalhost plugin uses a combination of HttpFilter and ThreadLocal to obtain and store the server name from HttpRequest.

The URL used in the command output is constructed using DynamicItem<UrlFormatter>, which in the DefaultUrlFormatter is obtaining hostname via constructor injection of @CanonicalWebUrl Provider<String>. It is important to note that the DefaultUrlFormatter is marked with @Singleton, which means that after initial creation the canonical web url will not change. But removing the annotation doesn't change anything. The VirtualHostHttpCanonicalWebUrlProvider will not be able to get the server name from the thread local anyway.

Digging deeper, the DynamicItem<UrlFormatter> is used in ChangeUtil#getChangeIdsFromFooter(), which is also a @Singleton (removing that annotation also didn't help), then eventually is called from ReceiveCommits#processCommandsUnsafe(). On this level, we have access to requestScopePropatator which will propagate the HTTP request scope to the background thread. This means we can do requestScopeapropagator(() -> processCommandsUnsafe(commands, progress)).run() and hope that @CanonicalWebUrl will be calculated correctly. Unfortunately, this way we'll be using members of ReceiveCommits that were created out of the HTTP scope and we'll still get an incorrect result.

I've also tried injecting Provider<ChangeUtil> into ReceiveCommits, hoping that this would create a new instance on each get() and resolve its dependencies in the context of the HTTP request. Unfortunately, no luck with that.

Maybe, extracting processCommandsUnsafe() to a class and injecting its provider into ReceiveCommits, then using that provider in requestScopePropagator.wrap() could solve this problem. But this feels too invasive for such a trivial problem.

For now, I'm out of ideas. This is clearly a problem with Guice scopes and injectors but it's not easy to be solved.