Result pages display the backend host

[takesson]

Not sure if this applies to all result pages.

Example:

New version committed
http://simonsoft.simonsoftcms.se:8090/svn/documentation/access.accs is at revision 4500

[solsson]

I can't confirm this with the docker-compose based stack. The apache host has a random hostname, I don't see ServerName enabled anywhere, and it reports the external http host at that location.

I'm surprised the setup is operational when reporting an internal URL there. Many links should fail. The result page uses getTargetUrl() which reuses the global getTargetUrl() which is documented as returns the absolute URL as the user knows it.. This is truly ancient code 😄 .

If I remember correctly you have some control over those URLs through getRepositoryRoot()'s and getHost()'s use of server vars, which I think propagate from SetEnv.

[takesson]

Not sure if this applies to all result pages.

Can see this on result pages for:

• Edit in repos
• add file
• lock / unlock

[takesson]

I can't confirm this with the docker-compose based stack. The apache host has a random hostname, I don't see ServerName enabled anywhere, and it reports the external http host at that location.

Is the svn backend url different from the external url? (apart from http/https)

I'm surprised the setup is operational when reporting an internal URL there. Many links should fail.

Any specific example that I can verify?

The result page uses getTargetUrl() which reuses the global getTargetUrl() which is documented as returns the absolute URL as the user knows it.. This is truly ancient code 😄 .

I think that documentation is optimistic 😄 .

It is not really necessary to display the full URL in the result pages. The user can just return to the details page to get the url. There is an issue with the encoding of file name appended to url as well (add file).

If I remember correctly you have some control over those URLs through getRepositoryRoot()'s and getHost()'s use of server vars, which I think propagate from SetEnv.

Yes, I have this config:

SetEnv REPOS_HOST "http://simonsoft.simonsoftcms.se:8090"

The reason is that "http://simonsoft.simonsoftcms.se" is running OpenIDC and the https can be done by a different host or a load balancer.

[takesson]

I'm surprised the setup is operational when reporting an internal URL there. Many links should fail.

Perhaps ProxyPassReverse does its job on href attributes.

[solsson]

How does svn copy work on this host? I ask because looking at how getTargetUrl() is used I suspect that the only difference between internal and external URLs that we support is TLS termination http<->https. Presentation uses asLink to display user-facing URLs. The tests for asLink are here. Maybe this limited scope is on par with svn's scope for when copy works.

[solsson]

Would links work if the port number is dropped? If so we could possibly wrap the URL with asLink and scope creep asLink to support dropping port numbers, by opt in using SetEnv for example.

[takesson]

How does svn copy work on this host?

• rweb copy works
• svn client copy works BUT that request is not proxied to the backend host, it is handles by the http host which does OpenIDC auth (the svn client presents a session Cookie).

I ask because looking at how getTargetUrl() is used I suspect that the only difference between internal and external URLs that we support is TLS termination http<->https. Presentation uses asLink to display user-facing URLs. The tests for asLink are here. Maybe this limited scope is on par with svn's scope for when copy works.

When the backend host is actually a different host ( e.g. actual backend cluster) the svn client copy will also have to be proxied. I expect to make that work by enhancing this Apache config a bit (the statement needs to be specific to the hostname and backend url):

RequestHeader edit Destination ^https http early

[takesson]

Would links work if the port number is dropped? If so we could possibly wrap the URL with asLink and scope creep asLink to support dropping port numbers, by opt in using SetEnv for example.

To clarify terminology:

• "links", aka href attributes work fine, handled by ProxyPassReverse
• "textual urls" display the backend url, classic issue in proxy situations

So let's consider what is the value of "textual urls"?

• Details / Edit page footer: huge value, works fine (not sure why)
• Result pages (only some result pages): no value or even negative value making the page more cluttered
• ...?

I suggest removing "textual urls" except Details / Edit page footer in order to stay within the classic limitations of proxy setups and also benefiting from its flexibility.

Just removing the port number would work now but not when using an actual backend cluster. I don't understand why this isn't an issue in most dockerized setups.

[takesson]

I have realised that ProxyPassReverse is not handling the links because the PHP handler executes in the normal http vhost and there is never any proxying to the backend svn host at this time (no future intention either).

Is the PHP code actually using getTargetUrl() for generating hrefs in pages? Using relative links would be less problematic.

[solsson]

Is the PHP code actually using getTargetUrl() for generating hrefs in pages?

Links should be relative. I think this issue is right to classify external-facing use of getTargetUrl() as a bug.

[solsson]

https://github.com/Reposoft/rweb/releases/tag/v1.8.4

[takesson]

Some clarification of earlier discussion:

• The ProxyPassReverse never processes href in the content. It only handles a few response headers, most importantly Location. It does not process the dav header Destination.
• The Destination header might no longer matter with modern svn clients (using Serf probably). Unable to reproduce the copy issue even if adding additional proxy of the svn traffic (not via rweb).