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 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.
Customer surveys are for companies who didn't pay proper attention to begin with.