The Problem
Have you seen a web site that makes you log in twice, for no good reason?
Have you ever had to move a bunch of web pages to another directory (URL level), or to a new server (or under a new domain name), only to find all the links and images broke; you have to edit every web page in a dozen places to fix it all?
These problems are easily solved when you know what's going on. Let's take a look.
The Solution
Use the shortest, most relative URLs you can, when referring to things within your web site (images, links/anchors).
For things in your current directory/folder, use only a filename
Example:
<a href="otherpage.html"> <img src="picture.jpg">
The reason is simple. Those other files are in "our directory", wherever that is on the system. You want to refer to those files with as little changeable information as possible. You don't want to specify the web site address/domain, it may change. You don't want to specify even what directory on the current web site it's in, if possible; you may move things around later!
Use relative paths for things nearby
If the files are not in the current directory but in one nearby, use relative paths. This follows the Unix syntax, where ".." means parent directory, and "/" is used to separate directories. Examples:
<a href="../cart/index.html"> <img src="../icons/picture.jpg">
Use absolute paths for global things
If the files are not in the current directory but are relative to the top of the web page area, you can refer to them by absolute directory path. This follows the Unix syntax, where ".." means parent directory, and "/" is used to separate directories. Examples:
<a href="/cart/index.html"> <img src="/icons/picture.jpg"> <a href="/index.html">Home Page</a>
Leave off the index page when web server defaults to it
Most web servers understand when a URL is a directory. They look for the "index" page in that directory. They usually look for: index.htm, index.html, index.php, index.cgi, and so on. This means you can leave that part off of the URL. And you should. You may have written the index page in HTML today, but maybe you'll use PHP or Perl CGI tomorrow! Don't limit your own future here. If you hardcode "index.html" today, and people bookmark that link, their bookmark will be no good later when you switch to PHP.
<a href="/cart/"> <a href="/">Home Page</a>
Leave off the web site if it's your own
Most web sites have multiple URLs, different ways to get there. The common duplicate is: most web sites like "www.something.com" work fine if you take off the "www" part (i.e. "something.com"). If both of those domain names work properly for every web page/file/image on your site, then why should you care? Good question. There are two problems that can occur.
1. Problem - User Authentication
Suppose you add user authentication to protect a web area, so only authorized users can access it. Let's say you use Basic authentication (built into most web servers) - it requires a username and password. Once entered, you're authenticated for all web pages on that server. Or are you? If a resource is referenced using the "other" domain name equivalent to yours, it will ask you to authenticate with that "other" domain -- even though it's exactly the same server and web pages! In other words, "something.com" and "www.something.com" are considered two different areas of authentication by the web browser! If the user browses to "something.com", and the web page has an image URL that starts with "http://www.something.com", then the user will be asked to re-enter their credentials a second time! This really irritates people. It's a sign of a poorly written web site - and is completely avoidable.
Solution to #1
You don't know what domain the person entered to reach your web page (either with, or without, the "www"). So, don't hardcode the domainname when referring to local resources and links. This will fix the problem.
2. Problem - SSL Security
Suppose you add an SSL certificate (https protocol) for a data-encrypted privacy web area, such as a shopping cart or something. That certificate is only good for a single domain name (either www.something.com OR something.com - pick one). You would have to have 2 different certificates, or pay for the more expensive certificate that covers the entire hierarchy of *.something.com. Why should you pay extra, when it doesn't add any value for you or your customers?
Solution to #2
You don't know what domain the person entered to reach your web page (either with, or without, the "www"). So, pick one of those and stick to it, for your SSL pages. Now, hardcode the path to the one you chose in all external pages (either with "www" or without). In other words, regular HTML pages that point to your SSL page should use your official chosen URL. all the web pages within the SSL site can still use relative paths, as described above.
Also, most web servers have a config setting to standardize the domain name for the user. If the user goes to "something.com", you can have the web server rewrite that to "www.something.com". The user will actually see it change on their browser. This is useful for SSL pages.
Don't make people type SSL page URLs
Never make people have to type the "s" in "https"; i.e. the URL:
https://www.something.com/cart.php
Always give them a way to get to that encrypted page thru a conventional URL, like:
http://www.something.com/cart/
How you do this is simple - you can write a short redirection web page. Create the "cart" directory in your regular HTML area. Create an index page, perhaps "index.htm", containing something like this:
<html> <head> <meta http-equiv="refresh" content="1;url=https://www.something.com/cart.php"> </head> </html>
This will make the user's web browser go to your SSL page after 1 second.
Some web developers fear ancient web browsers which don't understand Meta Refresh properly. That's why the redirect page is often written as follows:
<html> <head> <meta http-equiv="refresh" content="1;url=https://www.something.com/cart.php"> </head> <body> Redirecting you to the secure web site. <a href="https://www.something.com/cart.php"> Click here if you see this for more than 5 seconds. </a> </body> </html>
Summary
Keep your URLs as simple as possible, for a more professional web site.
Your customers will have a better time, and be more likely to bookmark your site and return again later.
Don't miss the latest web tips and tricks!
Subscribe to our low-volume mailing list:
Privacy Policy
| Copyright © 2006 Fastech Learning LLC, all rights reserved. |
| Phone toll free 1-866-464-6688, Phoenix Metro area 480-895-6688 |
| Problem with this web site? please let us know |
