Forum Moderators: phranque

Message Too Old, No Replies

what should I create a subdomain or a virtual host?

         

jnsunkersett

5:29 pm on Mar 4, 2011 (gmt 0)

10+ Year Member



Hi,

I am not a webmaster or an apache expert, but a j2ee developer.

I have developed a j2ee application and for my client can host it on a machine in a j2ee server having a public I.P address.

This way the application, should be accesible over the web, as [w.x.y.z...] where w.x.y.z is the public I.P address.

However, my client insists that I host it so that it is accesible under his existing registered domain ...eg; http: //www.existingDomain.com

He is adamant in not wanting to register w.x.y.z under a new name.

He insists, that current content which is viewable @ http: //www.existingDomain.com/curentContent, be kept undistrurbed and the new app should also be accesible on say something like http: //www.existingDomain.com/newApp

The website http: //www.existingDomain.com, uses Apache/ IIS or similar HTTPD software.

1. Is this demand, practically feasible ?

2. To achieve this, would I need to do ?

3. What would I need to get Created a subdomain or a Virtual-Host under http: //www.existingDomain.com ?

Off-course, I my j2ee app can funtion only on its own server specially built for it, I cannot simply copy it to some drive/ webspace and expect it to work.
ie. it is functionable only on the server w.x.y.z


But then what needs to be done so that requests coming to http: //www.existingDomain.com/newApp are served from the machine w.x.y.z?


Please advise.

Thank you.

Jeevan

BreathinBuddah

6:11 am on Mar 6, 2011 (gmt 0)

10+ Year Member



The simplest solution I can think of would be to use an <iframe>.


Set up an empty directory at [existingDomain.com...] with the following html:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<title>Your Application</title>
</head>
<body>
<iframe src="http://w.x.y.z/myapp," width="100%" height="100%">
<p>Your browser does not support iframes.</p>
<!-- the code inside the iframe tags does not display unless the browser doesn't support iframes or has them disabled -->
</iframe>
</body>
</html>


replace the "src" attribute with your apps URL

Peace

jdMorgan

5:45 pm on Mar 9, 2011 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



A subdomain of your client's domain can be pointed to your application server's IP address by using your client's existing DNS zone file and its 'control panel.'

Either your client, his staff, or his domain registrar should be able to do this easily.

Jim

jnsunkersett

6:14 am on Mar 11, 2011 (gmt 0)

10+ Year Member



Thank you Jim.

I shall advise my client appropriately.
However, this approach, I feel will have the following drawbacks...please comment.

1. A end user request, browsing to http: //www.existingDomain.com goes through (say) 'XX' hops on the world wide web and from there to reach the new application on w.x.y.z, it will go through an additional 'YY'number of hops.
This will be because the servers (http: //www.existingDomain.com) and the new server (@ w.x.y.z) are geograhpically seprated. (half way around the globe)

2. When the request/ traffic comes from www.existingDomain.com upto the new server w.x.y.z, it will be coming over the open IN-SECURE internet.
As a SSL certifcate cannot be re-used. My client already has a SSL issued for www.existingDomain.com, but I feel it cannot be used for securing the data flowing between existingDomain.com and w.x.y.z

3. My application communicates with external entities like payment gateways, which when responding, will respond to http: //www.existingDomain.com /newDomain ... (and taking point no. 1 above, into account), will mean the gateway-response will take more time to reach my application.

4. generally speaking, this introduces multiple multiple points of failure.

Are the above valid drawbacks?

thank you
~jeevan

jdMorgan

9:06 pm on Mar 17, 2011 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



The number of 'hops' for either server depends only on the routing from the client to the IP address of each server, as resolved by DNS. There are no "additional" hops, per se.

You've basically got a "fight" here between your client's very-understandable desire to maintain the "branding" of his own Web site, and the difficulty/possibility/feasibility/capability of your application to support the modifications necessary to make it function seamlessly with your both clients' domains and the supported payment gateways, while supporting the requirements for multiple security certificates to maintain the security of all transactions between the client's site, your application server, and the supported payment gateways. Frankly, I don't envy you this project... :o

Your client's concerns should be taken quite seriously. The desire to maintain branding is far more than just 'vanity. It is clearly documented that sites which switch to "unexpected" domains are considered far less trustworthy by an understandably-suspicious public than sites where the only switch is from HTTP to HTTPS when the cart is being accessed. The result of this is that conversions are higher on sites which appear to be entirely self-sufficient. With profit margins being driven ever-lower by competition and current economic realities, your clients' tolerance for *any* lost sales is likely very low.

In your position, I would be looking very hard at whether your application might be modified so that most of it could be hosted on the client's server using only a single (or a few) calls to your own server to verify that the client's license is current and valid for the requesting IP address(es). I'm not proposing this as an immediate solution though, because obviously you'll want to take steps to protect the proprietary parts of your application from being copied, and that is in itself a major undertaking. But simplifying and reducing the number of transactions, servers, and certificates involved in a session would likely be A Very Good Thing (TM).

Jim

caribguy

10:05 pm on Mar 17, 2011 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Is proxying the request, or setting up a tunnel between the client and your server a viable option?