jdMorgan - 5:35 am on Jan 5, 2007 (gmt 0)

From my little technical corner:

A URL rewrite and a URL redirect are two very different things. I try to make that clear by using the terms "internal rewrite" and "external redirect," or when feeling particularly pedantic, "server-internal rewrite" and "external client redirect."

A rewrite changes the server filepath associated with a requested URL. There is no required or fixed association between a URL and a file, and a rewrite occurring in the URL-to-filename translation phase of server processing can modify this association in almost any way that is desired; Almost any valid URL can be associated with almost any valid filepath, subject only to HTTP protocol and server access (security) restrictions. URL rewriting takes place within the context of a single HTTP request/response transaction.

A redirect, on the other hand, is a message sent by the server in response to a client (e.g. browser or robot) request. The message for a 301-Moved Permanently redirect says, "The resource you requested is no longer accessible at the URL you sent. Please update your link database and ask for it again by using this new URL." The sending of this redirect response ends the current HTTP transaction. The server includes the new URL in the redirect response, and it is up to the client to issue a new HTTP request, using the URL provided, to access the desired resource.

An interesting side-note: It was originally envisioned that when your browser received a 301-Moved Permanently redirect, it might pop a dialog box and ask you if you wanted to update your bookmarks accordingly. But the Web grew exponentially, search engines rose, and bookmark use dropped, while sloppily-architected sites proliferated, and this was no longer a workable idea. Now, only search engine robots make significant real-time use of redirect responses to update links.

Jim

[edited by: jdMorgan at 5:37 am (utc) on Jan. 5, 2007]