jdMorgan - 1:41 pm on Jul 24, 2010 (gmt 0)

And to add to that, the *rewriting* doesn't change the URL, *you* changed the URL that is published on your pages. URLs are defined and they "exist" the very moment they appear on a published Web page. This is where the "/article" path-part got added to the URL -- in the HTML on your pages.

When analyzing how all this works, it's best (easiest) to start by looking at the HTML on your Web page. That is "where the process starts" as regards the "action" of the Web. The simplest wya to get a handle on all this is to assume that the "action" starts with a click on a link on a Web page. What URL or URL-path-part is in that link? What canonical URL will the browser request (hover over it to find out) when it sees that link? And proceed from that point.

So, a click on an /article link, or an object-include of a page-relative-linked image/js/css file based on the current article URL being displayed in the browser's address bar results in the browser sending a request to your server with that "/article" path-part in the requested URL.

Your rule in Mod_rewrite then recognizes that as an "article" link, and rewrites that incoming request to the proper script filepath to generate a new page with that article on it and send that back to the browser...

Really no magic here, but as I've said, it's important to recognize URLs and filepaths as two entirely-different things, and to understand the "realms" in which they are used: URLs "out there" on the Web, and filepaths "in here" -- inside the server itself.

Once that concept "clicks," almost all of the confusion goes away... And I only say "almost" because I've just finished up on a site that had three "generations" of old shopping-cart-and-plugins URLs, and was transitioning to a fourth; Trying to keep all of those URL-types and old filepath-in-URL errors in mind while coding... well, no amount of book-learnin' can help with that! :o

Jim