Yes, I just discovered the same thing. Your proxy needs to append the port number if you are specifying it in VirtualHosts.ini.
But in the process of investigating this, I discovered a bug. If there is no virtual host match it should default to the *default* web root, not the last root mapped by a virtual host. This is fixed in the shortly arriving v7.0r1. > On Oct 2, 2017, at 11:03 AM, Doug Hall <doughall...@gmail.com> wrote: > > I've fixed it. Apparently, since the header information did not include the > port number, it resolved to the last known root, which was set by visiting > the url with the port number. I fixed it by removing everything after the @ > (including the port number) in my VirtualHosts.ini file, as follows: > > /* IP Address Hostname[:port] Language > Root Default */ > * localhost:8010 * > location_1_folder * > * name1@ * > location_1_folder * > * name2.localhost:8010 * > location_2_folder * > * name2@ * > location_2_folder * > > Perhaps there's a directive that I could have used to include the port > number in the request, but this seems to work, too. > > Thanks, for taking your time on this! The problem was located and > determined to reside between the chair and keyboard. :-) > > Doug > > On Mon, Oct 2, 2017 at 11:54 AM, Aparajita Fishman <aparaj...@aparajita.com> > wrote: > >> I'm looking into it. >> >>> On Oct 2, 2017, at 9:27 AM, Doug Hall <doughall...@gmail.com> wrote: >>> >>> Okay, I've dug a little further and have more information, now. It >> appears >>> to be a Virtualhosts.ini issue, not an nginx issue, but I can't be sure, >>> because going directly to the URL, (with the port number) bypasses nginx >>> altogether, and Active4D servers the correct website. I put a log message >>> in the On Web Connection method, to write the header information of the >>> request to a log file. First, my VirtualHosts.ini configuration, then the >>> request headers, with names changed to obscure the guilty: >>> >>> VirtualHosts.ini: >>> >>> /* IP Address Hostname[:port] Language >>> Root Default */ >>> * localhost:8010 * >>> location_1_folder * >>> * na...@.domain.com:8010 * >>> location_1_folder * >>> * name2.localhost:8010 * >>> location_2_folder * >>> * na...@.domain.com:8010 * >>> location_2_folder * >>> >>> >>> request header: >>> >>> 10/2/17 at 09:41:58: Header: GET >>> /index.a4d?fuseaction=<location_2_circuit>.main HTTP/1.0 >>> Accept: >>> text/html,application/xhtml+xml,application/xml;q=0.9, >> image/webp,image/apng,*/*;q=0.8 >>> Accept-Encoding: gzip, deflate >>> Accept-Language: en-US,en;q=0.8 >>> Connection: close >>> Cookie: c42_cookie_token=07l322blahblah; __utmc=135214817; >>> PROD=8BuOGblahblah; _ga=GA1.2.767blahblah; _gid=GA1.2.125blahblah >>> Host: name1temp.domain.com >>> Referer: http://name1temp.domain.com/ >>> Upgrade-Insecure-Requests: 1 >>> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) >>> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 >>> X-Forwarded-For: My_IP_Address >>> X-Real-IP: My_IP_Address >>> >>> Obviously, I've obscured my addresses and port numbers (for security), >> but >>> I actually did use the "@" in virtualhosts.ini to match "temp" at the end >>> of my hostname. Yes, that temporary URL is defined on our local DNS >> server. >>> >>> The point above, is that Active4D is serving circuit2's root folder even >>> though the header shows that it's receiving name1temp from my reverse >> proxy >>> configuration in nginx. Now, there's nothing in the header that says >>> anything about the port number, however it wouldn't have logged this >>> message had it not been sent to the correct port, so I'm not sure that's >> a >>> problem. >>> >>> Also, remember that the reverse happens, too. If I visit >>> name1temp.domain.com:8010 (I include the port number in the URL), then >>> thereafter, going to either name1temp.domain.com or name2temp.domain.com >>> (without the port number), will both resolve to name1's root folder. >> When I >>> visit name2temp.domain.com:8010. Then, it will always resolve to name2's >>> root folder, until I visit name1temp.domain.com:8010 again. >>> >>> Thanks for any assistance. I'm losing hair, over here. :-( >>> >>> Doug >>> >>> On Fri, Sep 29, 2017 at 1:58 PM, Doug Hall <doughall...@gmail.com> >> wrote: >>> >>>> I posted this on the NUG as well, but it may or may not be more relevant >>>> here: >>>> >>>> I am having some problems with my Nginx reverse proxy. I'm running >> 4Dv15, >>>> and Active4D 6.4r3, using the 4D server shell. I have successfully >>>> configured two web roots in Active4D, which run on the same 4D Web >> Client, >>>> on port 8010. I have two different host names which are pointed to the >> same >>>> IP address. I'll call them name1.domain.com:8010 and >> name2.domain.com:8010. >>>> These successfully resolve to the appropriate web root within Active4D, >>>> when I put those two urls in my web browser. >>>> >>>> I set up my proxy in nginx two different ways, and neither of them >>>> consistently resolve to the right website: >>>> >>>> 1: I setup one upstream server and accessed it through proxy_pass from >>>> both server definitions: >>>> >>>> upstream 4d_webclient{ >>>> server 127.0.0.1:8010; >>>> } >>>> >>>> server { >>>> listen 80; >>>> server_name name1.domain.com; >>>> >>>> location / { >>>> root /location_1 >>>> proxy_pass http://4d_webclient; >>>> ... >>>> } >>>> } >>>> >>>> server { >>>> listen 80; >>>> server_name name2.domain.com; >>>> >>>> location / { >>>> root /location_2 >>>> proxy_pass http://4d_webclient; >>>> ... >>>> } >>>> } >>>> >>>> Please note that I'm just trying to get the reverse proxy to work. Once >> I >>>> do that, I'll add SSL requirements, and all the necessary rewrites to >> make >>>> sure people are redirected to our secured interface. >>>> >>>> The second way I did it was to create a different upstream for each >>>> website, using the DNS names for each, and then calling the appropriate >>>> upstream proxy from each server definition: >>>> >>>> upstream name1_server{ >>>> server name1.domain.com:8010; >>>> } >>>> >>>> upstream name2_server{ >>>> server name2.domain.com:8010; >>>> } >>>> >>>> ... (the same as above, except replacing 4d_webclient with >> name1/2_server >>>> at proxy_pass) >>>> >>>> Both ways gave the same results. After restarting my Web Client and >> nginx >>>> (just to make sure I start from a clean slate), both name1.domain.comand >>>> name2.domain.com resolve to the name1:domain.com:8010 website. However, >>>> if I go to name2.domain.com:8010, then both name1.domain.com and name >>>> 2.domain.com will resolve to that website. Going to >> name1.domain.com:8010 then >>>> causes both portless addresses to resolve there, until I visit >>>> name2.domain.com:8010 directly again. >>>> >>>> Obviously, I don't understand the relationship between how nginx deals >>>> with upstream declarations and how that passes along to Active4D. Any >> help >>>> would be appreciated. >>>> >>>> Doug >>>> >>> _______________________________________________ >>> Active4D-dev mailing list >>> Active4D-dev@aparajitaworld.com >>> http://list.aparajitaworld.com/listinfo/active4d-dev >>> Archives: http://active4d-nabble.aparajitaworld.com/ >> >> _______________________________________________ >> Active4D-dev mailing list >> Active4D-dev@aparajitaworld.com >> http://list.aparajitaworld.com/listinfo/active4d-dev >> Archives: http://active4d-nabble.aparajitaworld.com/ > _______________________________________________ > Active4D-dev mailing list > Active4D-dev@aparajitaworld.com > http://list.aparajitaworld.com/listinfo/active4d-dev > Archives: http://active4d-nabble.aparajitaworld.com/ _______________________________________________ Active4D-dev mailing list Active4D-dev@aparajitaworld.com http://list.aparajitaworld.com/listinfo/active4d-dev Archives: http://active4d-nabble.aparajitaworld.com/
