Forum OpenACS Q&A: ns_conn location returning odd location

Collapse
1: ns_conn location returning odd location
Posted by Tony Kirkham on 05/19/21 09:38 PM

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-tcl and 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?

Thanks,

-Tony

Collapse
2: Re: ns_conn location returning odd location (response to 1)
Posted by Gustaf Neumann on 05/20/21 01:31 PM
The short answer is: is there a good reason not using "util_current_location"?

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. [1]). A quick test on openacs.org shows the right domain name.

Collapse
3: Re: ns_conn location returning odd location (response to 1)
Posted by Gustaf Neumann on 05/20/21 09:17 PM

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.

Collapse
4: Re: ns_conn location returning odd location (response to 1)
Posted by Gustaf Neumann on 05/28/21 04:04 PM
Just a small addon: from the point of view of NaviServer, it would be the best thing to use "ns_locationproc" to define the OpenACS understanding of the location (i.e. handling the OpenACS specific host-node map). The definition would be similar to "util_current_location" (without calling ns_conn from there). This would mean, one could use "ns_conn location" or "util_current_location" in essence interchangeable, it would not make a difference. This change would simplify usage for OpenACS users - and would be "the right thing" from the NaviServer perspective.

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.

Collapse
5: Re: ns_conn location returning odd location (response to 1)
Posted by Raul Rodriguez on 02/27/23 11:08 PM
Hi Gustaf,
How do we configure ns_locationproc?

From https://naviserver.sourceforge.io/n/naviserver/files/ns_locationproc.html
We copied the example code into config.tcl:

ns_locationproc   nstest::location arg
 proc nstest::location {args} {
    return "testlocation.$args"
}

and got:

[-main:conf-] Error: no initializing server
no initializing server
    while executing
"ns_locationproc   nstest::location arg"
(context: configuration) line 1044
[-main:conf-] Fatal: error in configuration file /usr/local/ns/config-oacs-5-10-0.tcl line 1044

Thank you for your help

Collapse
6: Re: ns_conn location returning odd location (response to 5)
Posted by Gustaf Neumann on 03/03/23 01:55 PM
Hi Raul,

The error message means that at the time this proc was called, the server was not yet defined. Simply speaking, you called the proc too early.

The configuration file determines several parameters which are applicable for multiple servers, later, the defined servers are initialized (loading modules, etc.). You can see this as well from the prefix used in the error.log.

When one loads this at some later time, - maybe in your OpenACS package nstest - you will see during sourcing a message like

[03/Mar/2023:13:19:38.295950][-main:oacs-5-10-] Notice: SOURCING location-procs.tcl

where "oacs-5-10" is the name of the server. Note that OpenACS has - since ages - several features controlled via package parameters and host-node map to produce its own understanding of the "current location" [1]. So, if you change the lower-level semantics, the likelihood to change some behavior is greater than 0.

The example in the man page is from the NaviServer regression test - so probably not the best. Put this following file e.g. to the "tcl" directory of one of your packages (using for instance the name location-procs.tcl).

namespace eval nstest {
    ns_locationproc ::nstest::location

    ad_proc ::nstest::location {args} {
        set location [ns_conn protocol]://[ns_set iget [ns_conn headers] host]
        ns_log notice "LOCATION-PROC args <$args> - location <$location>"
        return $location
    }
    ns_log notice "SOURCING location-procs.tcl <[ns_info server]>"
}

Hope, this helps.

The main question for me is, why you do not want to stick with the standard behavior.

all the best -g
[1] https://openacs.org/api-doc/proc-view?proc=util_current_location&source_p=1