Forum OpenACS Q&A: ns_conn location returning odd location
We are in the process of moving to the latest NaviServer 4.99.21 and we have found an oddity.
Prior to this move we have installed NaviServer 4.99.18 in a Docker container that had CentOS 7 as the container OS.
We are moving to NaviServer 4.99.21 in a Docker container that has Ubuntu 20.04. In the testing of our system we have found some strange behavior. The call
ns_conn location used to return the same response as
ad_url. It now returns one of the ip addresses reported from inside the container using hostname -I; so on this set-up
ad_url -> https://my.domain.name ns_conn location -> 192.168.176.27
Now when the call to
ns_conn location is used to create urls to send to the client, obviously they are broken links.
Has this happened because of some misconfiguration in this new system or is this an oddity of how Ubuntu in docker responds?
Also I can see that
ns_conn location is used in a few of the procs in the packages
acs-automated-testing. In our code we are changing from
ns_conn location to
ad_url, but I am not sure I want to change the core packages for this issue.
Any idea why this is happening?
Determining the "location" is complex (the same server might be reached over different domain names and drivers) and depends to a great deal on the virtual hosting setup or whether the server runs behind a reverse proxy.
Make sure, the OpenACS config file uses global modules (in ns/modules, see e.g. ). A quick test on openacs.org shows the right domain name.
I have check now the details, how the result of [ns_conn location] is determined in detail:
if "ns_locationproc" is configured, its result is returned.
if virtual hosting is enabled, and the "Host:" header field is provided and valid, it returns its content.
If everything above fails, it is determined by virtual hosts mapping table (as defined in the "ns/module/nssock/servers" or "ns/module/nsssl/servers" section in the configuration file).
If everything above fails, and a connection is open, it is determined by the current socket address.
If everything above fails, it is determined by configuration values of the driver.
I'll make sure that this is added to manual pages of NaviServer.
However, "ns_locationproc" is a NaviServer thingy, this would not work with AOLserver; ... so there would be the need for the time being for two implementations, with some more potential for breaking the setup on a few sites.