Redirecting - status codes and client-side methods
The client-side methods of redirection should only be used when the page being redirected away from has content that you want shown, for example, a landing page before redirecting to a file, such as Sourceforge does.
The main problem with redirecting on the client-side (besides users having to wait for an extra response body) is that search engines won’t follow the redirection, and therefore will continue to list the useless page, and user agents will also be unaware of the change. Sending a status code tells search engines and user agents exactly what the redirect is about, and therefore what it should do, that time as well as in the future.
There are two commonly used redirection status codes, 301 Permanently Moved and 302 Moved Temporarily / Found (in HTTP 1.1 there is also 307 Temporary Redirect which has the same function). I don’t believe any user agents handle the latter two codes differently.
If your page has permanently moved, for example you have obtained another domain and wish to stop using the old one, then the page that links to the old domain should then send the 301 status code, along with a Location header specifying the new address. Be aware, however, that according to specification user agents, upon recieving the 301 status code for a certain URL, should from then on always link to the new address specified in the Location field, without checking the old location for a status change. So, theoretically there is no turning back once the code is sent. I’m not sure, though, whether common agents that use the HTTP, such as modern browsers, actually implement that.
On the other hand, if you would simply like to temporarily redirect the page to another location, say from a long URL to a permalink-style address, then the 307 Temporary Redirect or 302 Found header should be sent (really, 307 is more correct but 302 is more popular). This will cause the user agent to retrieve the response from the URL specified, as before, in the Location header that must be sent, obviously, with the status code, but upon future requests the agent should check the old address first to see whether a status change has occured (because the redirection was only temporary), instead of automatically using the post-redirect URL. As a note, it seems that search engines, upon encountering a temporary redirect, will use the shorter URL, no matter which side of the redirect it is on. I’m investigating further, however.