Have you refreshed the browser cache after changing the value? The Filr web client is an AngularJS-based monster and caches a lot of things locally.
You can also try a "new" browser, as in a abrowser you haven't used with Filr yet.

If a cache refresh helps, this should be addressed in the code by e.g. setting a config-last-changed timestamp header by the server that a client can evaluate...

HTH!

I double-checked this - deleted cache in Firefox, installed Opera - the problem persists.

(But you are right, browser cache IS a problem with Filr: sometimes I don't see "My Files" and "Netfolders" after successful login, deleting browser cache helps in these cases.)

Interesting. Somewhere, the request seems to be rewritten. Can you use the Browser DevTools (usually F12) to check the link generated by the Filr Web UI? If that is the new URI, then use a client like wget or curl (both come with MobaXterm or cygwin) and you'll see easily where and when the rewrite happens.

We have multiple layers a t work here, web applications, tomcats, jettys, two SLESs and a docker container), so there's many moving parts that can be involved depending on the change you made (I have seen fun things happen if e.g. the hostname stayed but only the domain changed). This means places to also check can be:

• your reverse proxy configuration (have you set ProxyPass but not ProxyPassReverse?)
• hosts file of Filr (I have seen software use the given hostname to get the IP, then reverse-lookup the IP and use that name)
• your client hosts file
• network config of CE, if the hostname on eht0 might be involved ( https://<your-CE-host>:9443/vaconfig/network )
• your own proxy if you use one (I have seen behaviour like this a long time ago with long caching times on squid).

I think the most probable culprit could be the reverse proxy. Which one do you use?

I did not find the URL with DevTools - I don't know much about web development...

But I think the reverse proxy can be excluded: if I access filr directly on port 8443, then the reverse proxy should be out of the game.

I'll check the other point you mentioned....

Ok, possible misunderstanding found. The original post read as if CE is now behind a reverse proxy, so you - and Filr - would access CE via a reverse proxy that needs the reverse mapping enabled. It should not matter how you access Filr itself.

I would recommend just downloading a tool like the portable edition of MobaXterm (my weapon of choice, here) and run "wget --no-check-certificates <your-CE-URL>".

Alternatively, there's a Firefox extension called "Live HTTP Headers" that can help you see what happens.

I have now found it in the Developer Tools of Firefox - it was directly in front of my nose, but I looked somewere else...

There are <form> elements on the Filr pages with an action that contains the wrong URL to CE.

Ok. So it seems Filr accepts the change in the Admin-UI but doesn't use the value. Since you have already rebooted Filr, a service request seems in order. Before you do that you can use phpPgAdmin to check for the value of the column "loolserverurl" in the table "ss_zoneconfig" in your filr database. If that has the old URL, then you change did not get saved. If it has the new URL, and Filr was rebooted but doesn'T use it, then an SR is the only thing that can help, I guess.

I found now, this is a different problem. It's not that Filr retains some "old" settings, it just does not use the reverse proxy's URL but that of the internal content editor server. Obviously it learns the internal address by querying the proxy URL.

I have added a question to this thread: community.microfocus.com/.../1929574