Removing port number from URL on Apache server

The rules of URLs dictate that only the 'standard' port (80 in this case) does not need to be specified.  Any other port like 8888 needs to be part of the URL or the browser can't connect.  A virtual host won't change that requirement.

There are many posts on the Internet explaining how to do that to get around firewall and particularly closed ports problems. The objective is to get around that problem, loading getting the URL with a temporary port and then loading with port 80. From the examples it has worked for others but I haven't managed to get it to work myself. Even Apache manual says that one of the objectives of the proxy is to get around this type of firewall issue.

srv records are supposed to enable this functionality, but they are not fully used. in either  case as dave baldwin pointed out, http default to 80 with all others have to be explicitly referenced.

You need 2 virtual hosts defined: One for port 80, the other for port 8888.
Place the reverse proxy in the port 80 vhost section.

shalomc, will that remove the 8888 from the URL? Namely using what I placed above (with the 8888) in the port 80 vhost section? I ask as I'm tired of trial and error and very much look forward to do and success!

port 8888 site is that tomcat?
There are ways to use port 80 with workers that will query the tomcat app on the server invisible to the user, you reverse example also missing the url rewrite that strips and replaced the url in the response.
With a reverse proxy that will be distributing the requests based on the url you

arnold, it is Wamp. Your reply seemed to have been cut off. But, so I am sure to be on track, can you give an example? I was going to say brief but hard to make it long for that part. Thanks!

WAMP is listening on port 8888 what is on port 80 IIS?
No secure (ssl) available

IIS proxy for a specific host header request.

Look at squid reverse proxy to Apache that will proxy the requests further

In your example, if you have a site
Www.yourdomain.com has one functionality,
Using the mod_proxy config, you can have http://www.yourdomain.com/mysecondsite actually access the localhost:8888

Proxypass /mysecondite http://localhost:8888
ProxyReversePass http://localhost:8888 /mysecondsite

Looking back on your question, your forawrding/reverse proxy passing is the same which may explain the issue you had

One goes from 80 to 8888
The reverse needs to be reversed. From 8888 to 80

arnold, this is a development computer to be able to test new developments of the production environment. The problem is that the ISP blocks port 80, so we have to use another port. IIS is inactive; it's only Wamp. Finally, the current code changes the URL exactly to SSL. However, when it sees the port number in there it does not work. This coding should not be changed as the idea is to test the code and once it is working, be able to drop it straight into the production environment.

As such I need to be able to remove that 8888 from the URL.

the proxypass /reverseproxypass combination is what supposed to add and strip the URL of the final destiantion on the request/response side.

I am uncertain why you would need to have the test site exposed to the outside for testing purposes.

one option you could do is use the production site with an /nevertobeaccessrandomname which is the one that will proxy all the requests as well as restricting access to this path to avoid external access.

Is your site design such that it includes explicit urls or relative for links, objects,resources?
i.e. you have a PHP include configuration entry for $base_url=http://localhost:8888 etc.?

HTML code uses <Base href=http://localhost:8888/> to define the base of the page
et
if these two are not present, the paths within would be interpreted by the web browser as relative.

Your initially posted proxypass and reverseproxypass are the same which they must not be.
proxypass alters the incoming request to determine where the request should go, the reverseproxypass alters the URLS within the response that is then sent to the requesting browser/client.
i.e. http://www.yourdomain.com/somehome (which is seen be the proxypass as /somehome will be by proxypass changed to http://localhost:8888/somehome

When the response page is returned from port 8888, the reverseproxypass will replace the http://localhost:8888 with / or better using the http://www.yourdomain.com/

see if that makes a difference.

arnold, I'm glad you jumped in here. I took the examples which don't work from searches on the Internet -- and proxypass and reverseproxypass where always the same also for apparently removing the port number.

So to answer your question as to why external access? Because others develop something on a local machine and then want to see it in a real world environment, and also let others see it. As to security, one of the possibilities is an OpenVPN, but this seems (or seemed) simpler.

The machine has a dynamic domain (dyndom.com), so similar to what you mentioned. Now to make sure I understand (made confused by the wretched research).

"proxypass / www.dyndom.com:8888" would replace all with localhost?
"reverseproxypass / localhost" would replace localhost with www.dyndom.com:8888?

Or should I specify what it should be replaced with and not just a forward slash?

In the end, Arnold, the blocked ports are nearly impossible to get around. You have to essentially connect out to an external server to then set up the VPN. As a result I have opted for a low cost server with a service to get things moving, seeing as one of the tests would also involve mobile devices -- for which one would also have to connect to the VPN. This way everything connects, no matter what, best replicating the production environment we have.

 would recommend your looking into a new open VPN solution on www.softether.org. This was put together by a university in Japan and they have done an impressive job, superior to OpenVPN, with more alternatives and more security than OpenVPN. Even CNET mentioned that it is a very stable solution.

I will be closing this question giving the points to you. Clearly you know what you are talking about and ultimately helped me understand how things work and the options, plus the logic to arriving to the solution I am adopting, which I am also very grateful for.

Please see my comments before closing this issue.