Forums Register Login
From what domain (virtual host) did a request originate?
I have a web application that relies on parsing the URI for application logic.


Each piece of the URI means something, and it's currently implemented as a parsing filter.

The project sponsors really don't like all the cruf in the URI, so an alternate is to have a subdomain for each possible combination and then remove that combo from the URI. So now the 'switch' in the system is moved from the URI to the domain.


Our current architecture has one apache instance going through the jk connector to one tomcat instance. Plenty of virtual hosts, and I suppose I can setup multiple virtual hosts to point to the same webapp. If that assumption is wrong, I'm a bit sunk. Anyhow.. my question is this:

Once the request is at that application, what's the best way to determine from which virtual host it was sent?

One solution would be to chop of the URI (if any) part of the URL.
That would give me the http://abc.myfoo.com ort/ part. I could then chop from the "://" to the next "." to get my "abc" parsed out.

Perhaps though, I could use a header. Like 'referrer'. But I am always hearing about trouble with that particular header. Firewalls mess with it, proxies mess with it, privacy advocates mess with it. Perhaps a weird Apache/jk configuration messes with it.

What are the issues surrounding this? Which approach is recommended?

I haven't done any web programming in Java for a while, but from a protocol standpoint HTTP 1.1 requires clients to send a "Host: xxxxx" header. I don't know what you would do with HTTP 1.0 or less...
I suppose passing them as standard url parameters is out of the question also... :roll:
Personally, I would stick to your guns and explain to management how the technology (that is http requests) actually work. There is no use going thru a ton of additional and ultimately needless work because management doesn't like all that "stuff" in the url. Have you ever seen the types of urls created by Portal products? Now those are some scary urls!!!
As far as I can recall, Apache isn't going to modify the URI. You could just use the HttpServlet method that returns the URI and use the appropriate URL get method to extract the domain name from there.
I really don't recommend setting up a distinct domain name for each and every page in the webapp. If that's what you're up against, it's PHB syndrome and you're doomed.
On the other hand, limited URI encoding as an assist to fast direct access to frequently-accessed pages is IMHO a Good Thing. I always appreciate things like "http://search.javaranch.com" or "http://www.javaranch.com". It's quicker for me and fewer pages for the webapp to have to run me through, so less server load. For really important/common features, I'd go with a subdomain. For the rest, use the mapping capability in web.xml to map a simple URI (e.h. "/search") to the actual servlet or JSP.
Thanks Tim,
It's actually not that bad. There's not actually a single page mapped to any possible combination of a/b/c/ parameters.

The original complaint was that they didn't like:


So I went with

This looks much cleaner. First, the TRANS servlet will grab the request and translate a/b/c into yadda?foo=a&bar=b&baz=c
It then forwards.

But the project sponsors still aren't happy with the URL. So I'm left with one other option.


Now my TRANS servlet will be configured as the default servlet. The output will be the same (an URL with a querystring) which is then forwarded to. The parsing changes from URI-based to subdomain.
Thanks Chris,

The sponsors are Marketing, so it's hopeless anyways.

And yes, I'm aware of portal products. I used to work for the company that made this site, using divine(TM) Content Server (divine as a company is a dot-com bust).

Check that URL out, and see the URL *after* CS gets done with it. And that's not even the worst example of URL mangling.
... which is now FatWire Content Server.
I last worked for another company that divine bought and destroyed -- Northern Light.
What's that smell? Hey, sniff this tiny ad:
Why should you try IntelliJ IDEA ?

This thread has been viewed 818 times.

All times above are in ranch (not your local) time.
The current ranch time is
Aug 14, 2018 14:23:50.