Connection Refused error

Trying to get my head wrapped around why some users would get a connection refused error.

The server for this site contains a database listening on port 80 and a standalone Xoxo web app listening on port 8882 and I have complete control over the site amd know that all the ports concerned are open. It works for 99% of our end users.

The site is accessed using an address like this…

         http://mycoolsite.com/districtregistration

This hits the database which in turn does an http redirect to the Xojo weba app…

        http://mycoolsite.com:8882

The web app then takes over and all subsequent requests from the user are handled by the webapp. Queries by the webapp to the database are either a GET or a POST with a URL that looks like this…

         http://mycoolsite.com/myrequest?prarm1&param2

The end users are being denied access before the app completes loading. An open event on a container in the home page sends a GET to the database for header information. I suspect that this GET command which uses port 8882 is where the rejection occurs.

Given this setup is it possible that the Connection Refused error is being generated by the end user’s firewall? Would they need to open up port 8882? If so I do not understand why their firewall blocks an outgoing port.

Thanks,

John

Why do you have a database running on port 80?
Port 80 is used by the web server so that should not work.

How does your database do an http redirect? :slight_smile:

The database is a 4th Dimension database. It has a built in web server component listening on port 80 in place of the Apache Web Server which is turned off. It has a full complement of http, soap, xml, jason, etc. commands including http redirect. It has worked quite well for hundreds of our end users as I have described here. That is except for this connection refusal a couple of them are experiencing.

How many simultaneous users do you have?

[quote=221174:@John Baughman]Trying to get my head wrapped around why some users would get a connection refused error.

The server for this site contains a database listening on port 80 and a standalone Xoxo web app listening on port 8882 and I have complete control over the site amd know that all the ports concerned are open. It works for 99% of our end users.[/quote]

Could be that the 1% users who have a connection refused have a firewall where the unusual 8882 port is closed.

@Greg O’Lone This particular site just opened yesterday so no more than 1 or 2 at a time at the moment. When student classrooms start using, no more than 20 or 30.

@Michel Bujardet Yes 8882 is an unusual port and that is what I think is the problem, but I am having trouble understanding why.

The Xojo web app is listening on port 8882, but that is on my host server, right? The request from the end user’s browser goes out to the host server and port, why does the firewall care where the request is going? Or am I not understanding how Xojo works. Obviously I am no genius when it comes to network security.

In the end I will have 3 Xojo web apps running on the host server along with the database. My plan was to distribute the listening porst as follows…

  4D Database: 80
  XojoApp1: 8891
  XojoApp2: 8892
  XojoApp3: 8893

What 3 ports would be more likely accepted by most firewalls.

Thanks,

John

[quote=221447:@John Baughman]@Michel Bujardet Yes 8882 is an unusual port and that is what I think is the problem, but I am having trouble understanding why.

The Xojo web app is listening on port 8882, but that is on my host server, right? The request from the end user’s browser goes out to the host server and port, why does the firewall care where the request is going? Or am I not understanding how Xojo works. Obviously I am no genius when it comes to network security.[/quote]

It may very well not be Xojo at all. I rather suspect those customers machines have very tight security. Would that be a particularly paranoid anti virus, or an extremely cautious IT manager, it is perfectly possible to set a client firewall not to connect to anything besides 80 and 443. Standard http:// and https://.

If that is the case, then it is better to use a cgi build, as it will allow connecting to 80 quite normally.

You are probably right but for now it is too late to switch. We are deployed and I have never worked with a cgi which as I understand it I would require my 4D Server to be setlup as a proxy server which I don’t know how to do either. Maybe later.

For now I have changed this particularr Xojo web app to listen on port 8080, which I think most firewalls should not have any problem with, and I may switch the other web app to port 8008. When I get around to creating the 3rd and final web app for this project, I will probably have to figure out how to go cgi for all 3 as I don’t think there are any other recognized HTTP alternate ports.

Thanks for your input.

John