Relative URL's

[Dan Kaplan]

Here's something I don't see touched on too often -- the use of relative URL's.

For awhile now, I've been making use of relative URL's when ever possible to avoid the extra DNS lookup.[nbsp][nbsp]For example, instead of a link being http://mydomain.com/page1.html it would just be /page.html (or page.html if being called from the same directory).

Other examples would be,

../page.html (go up one directory level)
../../page.html (up two levels)
/page.html (root level)
etc.

Pretty simple.[nbsp][nbsp]However, I noticed that IE does not like /page.html if the page doing the calling resides in the cgi-bin.[nbsp][nbsp]Instead of going up to the root level, it always seems to stay in the current cgi directory.[nbsp][nbsp]To go up one level, ../page.html works fine, though.

Additionally, I've been told IE5 does something funny with relative URL's, but I haven't gotten a description yet as to what exactly.

I always call images in the same way (/images/image.gif for example), and that always works regardless of where they are called from.[nbsp][nbsp]I'm guessing the explanation has something to do with the image loading being server side, while the link is client side.[nbsp][nbsp]Anything client side would be dependent on the browser.

After my recent domain transfers and apparent browser caching IP problem, I'm wondering if any of this is even necessary?[nbsp][nbsp]Do all of the major browsers cache the IP?[nbsp][nbsp]If so, I imagine there are no subsequent DNS lookups after the initial one.

Thanks,
Dan

[Deb]

I have a really bad habit of using both methods of relative and long form. (best to decide on one or the other I guess).

I use to love relative links simply because they were faster and it was easier to move the entire web site to another domain name w/o having to change all of the links.[nbsp][nbsp]Everything just works as long as I keep my directory structure the same.

However, since I began using a lot of IROs (multiple domain names overlaying the same web site) I've found that going long form is better.[nbsp][nbsp]Browsers seem to be caching by domain name for things like images. If the visitor enters using a different domain name than they used the first time they end up having to re-download all of the images that they already have cached.

Browser sees...
[nbsp][nbsp]/images/graphic.gif as whateverdomain.com/images/graphics.gif

If visitor goes in on 2nd domain name to the same site browser will see
[nbsp]/images/graphic.gif as
2nddomain.com/images/graphics.gif and re-download it.

If I use
http://www.whateverdomain.com/images/graphics.gif then it doesn't matter what domain the visitor uses to enter as long as they have that image cached since the browser sees the same link....

I've found pros and cons to both methods.[nbsp][nbsp]And YES It is a good subject that I think a lot of HTMLers should explore.

Deb
[nbsp]--
[nbsp]Can't we just download the entire Internet and access it locally?

[Monty]

I have to agree with Deb, about using the longer form.[nbsp][nbsp]I came from a NT site, with full Front Page extensions (not knowing any better), and can tell you it was some kind of experience getting all those pages to work correctly here.[nbsp][nbsp]My site has 3 sites overlayed on it, with 2 more coming next week and if you are going to do any of that, the long form is the way to go.[nbsp][nbsp]This is especially true when using .cgi to call images, as in a message board format.[nbsp][nbsp]Much easier to just type the whole URL for the image once than to have it all jumping around.

Monty, just a fisherman having fun.

[Dan Kaplan]

Thanks for the responses.[nbsp][nbsp]Leave it to someone that not only openly supports, but encourages, the use of IRO's to point that out. ;)[nbsp][nbsp] I hadn't considered that aspect for images.

I suppose if you're going to follow that reasoning for images, there's no reason to do differently for URL's.[nbsp][nbsp]Consistency is a good thing.[nbsp][nbsp]Of course, previewing pages off-line becomes difficult...

Dan

[Justin]

Also consider that http://domain.com/ and http://www.domain.com/ are seen as different URL's by the browser.

As for relative URL's, this is *all* client side. The browser has the burden of putting the URL together - you could not send a network request for /images/pic.gif as there is no domain by that name :)

There is no DNS lookup no matter which way you go - again, either way the browser is going to request the full URL. In reality, the browser has to parse apart the URL. Say you request http://www.domain.com/images/image.gif - the browser does this:

Lookup www.domain.com (http://www.domain.com) on port 80
Connect to IP address, send HOST header to specify which domain is being looked for (HTTP/1.1)
Send request "GET /images/image.gif" (along with sending cookie info, browser information, IP address, etc)

The http:// part is not used by any part of the network other than the web browser itself, to determine what port/protocol to use.

At any rate, browsers cache the DNS for *at least* 5 minutes, usually much longer. There is no need to lookup the DNS over and over again, as domains usually do not move that often. ISP's also cache DNS entries for the same reason (these are all reasons that contribute to the problems experienced when transfering a domain).

I personally use fully qualified URL's, because I do not like putting trust into the browser. I can't possibly test *all* browsers, and all it takes is for a buggy version of Netscape to be release that forces *everyone* to have to use full URL's. Just like you have to make sure your text boxes are smaller than the table they are inside or some people using 4.07 won't see your form...

Plus of course if they use the "www" one time and not the next, the images will still pull from cache. I admit I am lazy and do sometimes use relative URL's (for example, the CNC has to use relative paths because it can be called from *any* domain on the servers ;) )

I'm going to stop ranting now and drink some more coffee...

------------------
Justin Nelson
FutureQuest Support

[sheila]

This is an interesting discussion. I've been using relative URLs on my pages, but I have a duplicate of my site on my home machine (it is a small site and not too fancy), and if I did long ones, that wouldn't work on my local machine.

But Justin's point about using full URLs to avoid problems with buggy browsers intrigues me. I have[nbsp][nbsp]had some people who had trouble with a e_Board discussion board that I installed a while back. I wonder...is it possible to use full URLs vs. relative URLs in cgi-scripts? (I don't think so...?)

Just thinking out loud.

And, yes, coffee sounds good. I'm going to go make some now.

[Justin]

IE *very rarely* crashes on me... and I do not see how @Home can say what they said, as IE5 is far less buggy than IE4 was... in either case, Netscape crashes every time I use it - hit a shockwave site and it's 50/50 chance of a crash for me (4.08).

But we don't need to get into an IE vs Netscape debate - everyone has their preferences (Unix vs NT, IE vs Netscape, Chevy vs Ford, Joe vs The Volcano, Miranda vs Arizona... ;) )

At any rate, I have never seen URL problems in IE, though I have seen people improperly use the "base href" tag, which I don't think is part of the HTML specifications - base href being your base URL, which tells the browser that all links on the page are relative to the base href rather than the location of the document... any browser that does not recognize this tag will of course not be able to reach the links (I believe this is a lazy person thing, but I am the king of lazy and would never use a base href tag...)

Relative URL's are ok for any purpose, and I haven't seen any cases where it would be a problem - I was just thinking of future Netscape bugs, but I have a feeling Netscape is gone for good. I am so <cough> sad </cough>.

I do use relative URL's at times, though in a CGI script you can easily use a variable to add the rest of the URL to each link - I just chose not to in the CNC... Relative is good when you are working locally and uploading later, or working in a temp directory to be later moved, and so on - but for the final product I usually try to use full URL's at least for images...

I guess there are good arguments either way, so my suggestion is to simply use whichever method seems most appropriate for the task at hand :)

------------------
Justin Nelson
FutureQuest Support

[Dan Kaplan]

Cut and paste time...

Also consider that http://domain.com/ and http://www.domain.com/ are seen as different URL's by the browser.
I thought I had that problem beat with relative URL's, only to start this discussion and realize the error of my ways.[nbsp][nbsp]I suppose the only thing to do is pick one and be consistent.[nbsp][nbsp]After the initial page, assuming you are using the full URL, all subsequent pages should be forced onto the same system.

I stand corrected about images being server side.[nbsp][nbsp]Good to know.

I can't possibly test *all* browsers, and all it takes is for a buggy version of Netscape to be release that forces *everyone* to have to use full URL's.
Obviously, we have a very big difference of opinion here.[nbsp][nbsp];)[nbsp][nbsp] My experience is that IE is the one that is very inconsistent in how it handles relative paths, graphics, DHTML, etc.[nbsp][nbsp]I have never seen, or had reported to me, any problems with Netscape.

At one point not too long ago, I tested a fairly simple page (just tables and graphics) in 9 different installations of IE on 5 different computers, and they all handled them drastically differently! :([nbsp][nbsp]In one case, reinstalling (I had no choice, also known as reformatting) fixed the problems...

My understanding is that browsers have gotten so complex that they require to be pretty closely tied to the operating system.[nbsp][nbsp]Obviously, IE has a big advantage over Netscape on the majority of computers, in this light.[nbsp][nbsp]That's the explanation I've seen why Netscape crashes so often.[nbsp][nbsp]On the other hand, I'm guessing that IE's close tie-in with Windows is partially responsible for the inconsistencies I've seen.

And as far as Netscape being buggy, I was told not to install IE5 by @Home because they consider it buggy software.[nbsp][nbsp]They claim Microsoft has admitted that, but I can't back up that claim.[nbsp][nbsp]At any rate, I was having problems with the IE4 that came on this computer, so I decided to upgrade to IE5.[nbsp][nbsp]That caused serious system crashes.[nbsp][nbsp]Going back to IE4 cleared up most of the problems...

Ok, enough of that morning rant.

is it possible to use full URLs vs. relative URLs in cgi-scripts?
Unless the script specifically says to use relative paths, there shouldn't be a problem.[nbsp][nbsp]I've used both at different times, and after reading this discussion just switched them all over to full paths without any troubles.[nbsp][nbsp]:)

Dan