Rewrite Base URL without Redirecting

Making the ip address in the addres bar look like the domain name

[lady_j]

This seems like it should be a ridiculously easy problem to solve, but I've been bashing my head against it across the internet for three days now.

I have a domain name reserved through yahoo business, and set to forward to the ip address of the server (on port 8080, since Clearwire blocks port 80.) I can't change the CName/A records because they don't accept ports; masked forwarding is not an option because of its usual set of problems.

When the user types in the url (http://www.example.com) they're brought to the homepage and showed the ip (http://123.123.123.123:8080/), the same for all subpages.

I attempted to follow the directions at [webmasterworld.com ] , but that created a problem because it redirected the user to http://www.example.com, which is not where it's hosted. Is there a way, using apache 2.2 on a windows box (either through httpd.conf or .htaccess), basic html files, or free online services, to force the address in the address bar to show as http://www.example.com/ (and maintain this through all subpages with appropriate subpage names being shown) while NOT redirecting them away from the ip? Even leaving off the [R], it automatically redirects when the http:// is include; if I change it to remove the http:// it ends up in an infinite loop.

[jdMorgan]

No, it's not ridiculously easy, it's impossible. The client browser shows the URL that it is fetching from, as it should for the user's security. Remember, the user owns the browser, and the browser --not the server-- is in control. That's where the client/server (as in "customer/waiter") terminology comes from.

You are heading down a path that I cannot recommend here -- trying to host on what sounds like a home server, and using an ISP that apparently frowns on home hosting. Not to mention the costs you will incur -- having redundant power, internet connection, and air conditioning installed, answering the phone 24 hours a day, seven days a week, keeping software up-to-date, fighting off intrusion attempts, providing user help and support... All these things would be provided by any decent hosting company.

If your ISP forbids or discourages running a server --as most do, since it upsets the upload/download bandwidth balance of their network-- they may well cancel your service as soon as they review the traffic stats across your subnet. Check their terms of service carefully...

Not to mention that a "forwarded" domain will never likely do as well in search results as a normal set-up.

Earnestly, do yourself a favor: Get a real hosting service with real DNS service. It will save you both time and money, and allow you to take time away from your server for such luxuries as friends and family... Cheap hosting is the most expensive in the world because of technical limitations and the extra time it will require from you.

If you really want to spend your life babysitting your server, then look into the various "Dynamic DNS" services that are available.

Best,
Jim

[lady_j]

Sadly, it is a non-profit organization's server, as opposed to a home server. Due to the nature of the organization, they already have redundant power, a static ip with uptime guarantee (they pay us for every minute we aren't up). There is no phone--it's not a business, there are no transactions. The reason for hosting it 'ourselves' is that a primary purpose of the website is to provide access to control software that is located on the server machine (for night-time off hours observing using the antenna), so we have to have the machine up and running and protected/defended 24/7 anyway. Our ISP has "agreed" that as long as we receive fewer than 100 visitors a day (which I doubt we ever will) we can host on our current plan in peace. The website is basically a replacement for our current vpn solution, which is ridiculously difficult to appropriately secure, maintain, and manage--search results are not a concern, as it is a site mainly for people who know about it.

I have looked into the dynamic DNS services, but they all seem (on the surface) to provide the same functionality as the yahoo business hosting--namely, provide forwarding in the event that you can't use a traditional CName/A Record for the DNS.

Even if I were to move to hosting the front-end materials on a web-based hosting service, the apache server/computer would still have to be there for the hardware-side controls, and would still be vulnerable due to its connection to the hosted website (which I would most likely be redirecting to this ip for the server-side software, rather than uploading the code and 'trusting' the host with it, and therefore still need to be able to let the user know it's the same website.)

The only reason I'm not happy leaving it at just the ip address is that, again due to the nature of the organization, a large number of the users are elderly and very easily confused--when they see an ip address, they assume it's a virus and immediately exit their browser and send me an email that the website's been "hacked."

[jdMorgan]

Then take the option to set up *some* kind of account with a 'real' registrar that can point the domain name to your IP address and use an ISP that lets you use port 80.

Basically, insist on a "standard" DNS and internet connection (port 80). If that turns out to be truly impossible, then a standard Webserver with your domain as the hostname could be used to reverse-proxy (*Not redirect*) the antenna control interface (or just its command and status requests) from the front-end domain-named server to the back-end IP-address based server. With this set-up, the users would see only the front-end server, and be unaware that the command/control was actually being done on the back-end server.

The reason I'm pushing for a standard set-up here is that of all of the "unsolvable" problems we see here in this forum --the ones where no resolution is possible, or where the poster just gives up out of frustration-- the vast majority are due to "weird" hosting set-ups. They are just too complicated, or too technically-limited, or take too much maintenance work over the long run...

The only major problem I see here is the ISP's port 80 restriction.

Jim