jdMorgan - 6:28 am on Jul 23, 2010 (gmt 0)

You are greatly confusing URLs (seen in on-page links and includes by browsers and sent by browsers to servers in requests) and filepaths (used only inside servers, and totally unknown to browsers). The specific point of confusion is your impression that a browser could have any idea of DocumentRoot... It cannot, barring any catastrophic SEO/mod_rewrite/scripting errors.

In essence, you have added a subdirectory called "/article" to all of your URLs, and put the /article-name after that. So the browser sees that "page" (resource) as "/article-name" in "/article" directory.

Therefore, if you use a relative link on the "/article/article-name" page such as <img src="img.gif"> then as g1smd has explained, the browser will look at the current page's URL "http://example.com/article/article-name" as shown it its address bar, remove "article-name", and then request that image using the URL "http://example.com/article/img.src".

By using a server-relative link <img src="/img.src">, you tell the browser to remove both the page name and all subdirectory path-info from the page URL, and then append the "/img.src", making the image URL "example.com/img.src". You could of course also use a canonical URL and specify <img src="http://example.com/img.src">, in which case the browser does not refer to the currently-displayed page's URL at all.

URLs are used "out on the Web" and filepaths are used only inside servers. Browsers requests objects from servers by sending a URL to the server. The server 'translates' that to a request for a static file and returns that file's contents. Or it translates the requested URL to a script filepath, and the script generates the 'content' to be sent back to the browser. Or the server finds that no static file exists, and no directive is present that can be used to map the requested URL to any script, and in that case, the server generates an error response 404-Not Found.

Nothing too difficult at all (which is why you can run a pretty decent server on a very old PC), but you've got to keep the URL-domain and the file-domain separate when thinking about things...

Mod_rewrite lives right at the boundary of the server, just past the entrance where requests come in. It can intercept a URL request and modify the way that the server translates it to a filepath access.

Seriously, install the "Live HTTP Headers" add-on for Firefox and play with it. Look at the browser requests followed by the server responses, using simple non-rewritten URLs on a few simple pages of a site that you understand well. And keep in mind that URLs are not files and that files are not URLs, and that in fact, they need have no correspondence at all -- It is only the action of a server that associates an incoming URL request with a filepath.

Compare what you see in the Live HTTP Headers window to what you see in your server access and error logs. Note that the access logs shows URLs, while the error log shows filepaths.

That should take a lot of 'mystery' and apparent inconsistency out of this exercise for you, and save you tons of time and frustration... This is the 'deception' of high-level scripting languages and CMS packages: They lead people to believe that they can create Web sites without learning about servers and the HTTP protocol -- all those annoying little details. :) While that is partially true, as soon as you get into anything the least bit complicated, it turns false -- and fast. In fact, if you were to suspend all current projects for two weeks and go study the server documentation and the HTTP protocol specification --and I mean read *all* of it, I'd wager that by the end of this year, you would be *far* ahead of schedule. No more time or money wasted because of misconceptions...

Jim