http://www/

[xmtb26]

Internally, our Systems Dept sets our users' browsers to

http://www/.

Don't ask why, but it makes life easier for them. I am in the Web Dept, and it drives us nuts. One of the biggest problems is our internal users email hyperlinks to external people as

http://www/dir/somedoc.htm.

This, of course, will fail (404).

Is the anyway we can do something in the Apache httpd.conf to force it to be fully qualified, i.e.,

http://www.ourbusiness.com/?

Everything we do seems to cause the server to constantly redirect back to itself (i.e., an endless loop).

 

[smah]

The way that I read what you've written, there's really nothing that you can do from the apache side..... an external mail recipient gets a mail message with some non-FQDN url. For the external mail recipient, this URL won't even resolve to your web server - are you sure the external recipient gets a 404 error, or is it a DNS failure error?

 

[RhythmAce]

I read this a few times and I can't figure out what it is you want apache to do. It sounds like somebody configured your browsers funky and you want to know if there is anything you can do to make apache fix their mail? Sorry for asking but can your rephrase your question?

 

[xmtb26]

Thanks for your patience.

It is a battle that could instantly be resolved if the Systems Dept didn't win out over the Web Dept. It be resolved quickly if the browser home page was set to

http://www.ourbusiness.com/

instead of

http://www/.

What happens when an internal user email a cut&pasted hyperlink to an external customer:
- the link in their email works fine for the internal user, because internally

http://www/

resolves to our web server.
- externally it resolves to "unable to connect" if the external customer doesn't have a mapping from

http://www to

their own web server, and if they do--they get a 404 as (of course) the file doesn't reside on their server.

As you know, in the Apache httpd.conf, it is easy to redirect requests from one directory to say another directory. For example, someone types in

http://www.ourbusiness.com/dir1/afile.htm

and next thing the user knows is they are sitting at

http://www.ourbusiness.com/newdir1/newdir2/afile.htm.

Therefore, based on this redirect idea, some think it should be possible to redirect

http://www/

or docroot back to

http://www.ourbusiness.com/.

 

[thedaver]

I see what you're saying, but it doesn't solve the problem.

Case: Internal user goes to '

http://www',

DNS resolves to the proper page and the internal user is happy. FURTHER, the internal user has no incentive to use the FQDN and will, as a consequence, continue to use the Short Form Domain Name ("SFDN") in communications to customers.

Case: External customer tries to click on a link bearing hostname '

http://www',

there is NOTHING you can do in apache to solve this since the hostname will NOT RESOLVE back to anything remotely close to your host. At best, it will resolve back to a host 'www' in that customer's own domain/DNS.

From a business perspective, you need to win the battle with the systems people. There is a BUSINESS RISK and a REPUTATIONAL RISK being posed by your SFDN being given to external DNS users who cannot utilize the value in your web services. As a result, your reputation is tarnished as a business and your business loses on the opportunities for which you made the investment in the web services in the first place.

Frankly, if the internal user community were having so much trouble with using FQDN in the first place, I'd have serious questions about whether I'd staffed correctly.

I'll be they have no problem typing

http://www.amazon.com

and

http://www.yahoo.com.

In short, there is NO WAY you can SOLVE a problem where a remote user is given

http://www/

and have them come back to YOUR web server.




D.E.R. Management - IT Project Management Consulting

http://www.dermanagement.com/

 

[xmtb26]

You have summed it up perfectly.

Our Web Dept does need to win the battle with the Systems people. The "bumping of heads" between the two departments has been ongoing for years. The worse part is that we are a government agency, and thus not doing the best for the taxpayer.

I will see if our management will reengage this particular issue.

 

[RhythmAce]

I see a little tiny light trying to come on. So in other words, the systems guys have a lot more power than just setting the home page in a browser. They control all the servers at the system level and the web guys control the web pages. Is that correct? My question is, where are they getting these links they are cutting and pasting and don't you guys have control over that? Sorry if these questions sound a little dumb but the lights are all the way on yet. What we are shooting for is a solution that maks both departments happy. So my questions are aimed at finding who controls what? Why can't they do certain things? And is there a way to accomplish what they need without messing up people in the real world?

 

[xmtb26]

We, the Web Dept, use relative paths where ever we can. (I can't go into why but for this discussion just consider it a must.) Therefore, the relative link basically inherits what the internal user has set for their homepage. So, this internal user is routinely corresponding to other external people via email where they cut&paste links from their browser into the email message. And, thus, the issue with

http://www/...

begins.

Our office then usually get a call or an email from the internal customer saying "the external customer clicks the link I sent them, and it doesn't work -- but when I click it, it does work." Or even worse, they don't say anything and attempt to live with the problem.

The latter statement is a key point. The users (both internal and external) don't complain as much as we'd like. At least with complaints, we'd have some sort of documentation to offer us support in trying to get change.

Our agency does have a "problem report system" but most users don't even know about it or have been trained about it. They call the Help Desk (who are the from end to the Systems Dept).

As a funny side note: they are looking for a "manager" that will act as a "go between" between the Systems Dept and the customers and Web Dept. It will be a thankless job, and a job that really shouldn't need to be done. (Thank god we have not been sucked up into the Systems Dept.)

I apologize this is straying off the original

http://www/

topic.

 

[RhythmAce]

I find myself in whole hearted agreement with thedaver. The systems department wants to build its castles in the sky and the web department is obliged to live in those castles. There are a plethora of ISPs and hosting companies out there that manage to get by without resorting to this level of paranoia.