Lo, Eddie, See infra:
<snip> > How many different host/port combinations are the applications you use > this strategy in deployed to? </snip> Thousands. <snip> > In the environment I "live", apps deploy on multiple servers (always > 2+ for high availability), and are likely to be accessed by a > different (non-standard) port for each instance. How can you, given > that criteria, construct a URL that will work? </snip> Depends on how you do things. Generally speaking, however, the issues are not so diverse as you might think. I won't talk about some specialized and difficult issues that you are very unlikely to face. Whatever URLs you are using are all resolving to the same IP address and then are being allocated internally. The actual "English" URL never made a difference anyway. <snip> > I disagree. It can make a huge amount of sense to have a web service > that exists only behind a firewall. You just haven't seen the > usefulness of it yet ... </snip> Nope, I haven't. The sense that I was talking about had a web service firewalling those that want to use it. That is what was not useful in the "scenario" I was talking about. That is almost tautological, isn't it? This is the only sense in which a firewall could impact the suggestion I was making. Suppose for example, that you have a firewall that keeps machines external to an intranet from accessing the intranet. If you don't want those people accessing your machines, then that hardly causes a problem for this solution. The comment I was responding to, which is an important context to my statements was David's note as follows: <snip> It doesn't make sense to assume that the web service installed on the client inside some network will be reachable from the external network. If this is what you're doing, configuration (having the client app user set the URL) is the only way to set it up because they (the client) will likely need to open up some incoming requests that they normally would not allow through their firewalls anyway. Not to mention whatever you grab would be the "internal" ip addresses. If your server grabs the ip from the request, it is likely to a proxy somewhere and not to your app. </snip> If I understand David, and maybe I don't, he is thinking that internal routing needs to be known by outside clients, in addition to the "external" IP addresses. Actually, there are no "internal" IP addresses. The Internet Protocol is external only. Right? Now, if you are talking about intranets that excluded access from the Internet, then you are talking about something totally different than the entire conversation and I was not addressing that issue. I think I was okay to assume that all this talk about URLs was about Internet and not intranet addresses. So, Eddie, I assume you are talking about some use of web services outside the context of the discussion when you say: <snip> It can make a huge amount of sense to have a web service that exists only behind a firewall. You just haven't seen the usefulness of it yet ... </snip> The other alternative is that you mean that there is a firewall but that the web service port is not firewalled. If that is the case, then you are talking about an issue that was addressed in detail in the thread and you might have missed. I discussed how to get the proper port, if that is what you are talking about. I guess I should just ask you directly: what in the hay are you talking about? Don't keep it a secret. ;-) Jack -- ------------------------------ "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ "You can't wake a person who is pretending to be asleep." ~Native Proverb~ "Each man is good in His sight. It is not necessary for eagles to be crows." ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ ----------------------------------------------- "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
