.htaccess for MVC with CSS problem

mod_rewrite is breaking links to css files

[gargantuan]

Hi there peeps. Long time listener, first time caller here.

::UPDATE:: I've been told this may be a problem with MAMP, I'm still looking into it.

My problem is, I am building my own MVC framework based on various articles around the web. Obviously it needs a .htaccess file and I'm using the following

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?rt=$1 [L,QSA]

I'll admit it, mod_rewrite is a mystery too me and this is lifted straight from another tutorial. It does almost exaclty what i want which is allow me to parse urls like

[myap.com...]

The problem I'm having is with the CSS files. If I navigate to "http://myapp/" everything works as expected. The same for if I navigate to "http://myapp/someController". The css is included and everything looks nice.

But the second I add a trailing slash to the url, the css stops being included. Now as I understand it, these two conditions...

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

...should prevent mod_rewrite doing anything if the url points to an actual file or directory. But when I navigate to something like "http://myapp/somcontroller/someaction" i can see in my error console that the site is trying to load the css from "/somecontroller/someaction/css/style.css"

likewise, if i try "myapp/somecontroller/" the site tries to find css in "somecontroller/css/styles.css".

I've searched around, but my lack of understanding with regard to mod_rewrite and especially regex is crippling me. I tried adding the following condition

RewriteCond %{REQUEST_URI} !\..+$

which (as I understand it) should prevent the rule being applied if the url ends in a file extension.

Sorry if this is a bit wordy. Any help, tips, pointers would be greatly appreciated.

thanks
-t

[edited by: gargantuan at 8:22 pm (utc) on Jan. 7, 2009]

[jdMorgan]

Your original rule is OK, even though the unconditional filesystem checks for every object requested from your server are quite inefficient. But I suspect your problem is that you have linked to your CSS, images, media, or external JS files using page-relative links on your pages.

Understand that it is the browser that resolves relative links, based on the directory-level showing in its address bar. So if the browser sees the line:

<link rel="stylesheet" type="text/css" href="mystyle.css">

in your HTML, and it is looking at the URL

example.com/controller/action

then it will resolve the CSS file's URL as

example.com/controller/mystyle.css

However, if you add a slash, so that the browser is looking at the URL

example.com/controller/action/

then the browser will resolve that relative css link as

example.com/controller/action/mystyle.css

The same applies for relative links to any other kinds of objects. Search engine robots behave identically to browsers when resolving relative links.

The easiest fix is to use server-relative or canonical URLs in your on-page links and object includes, e.g.
<link rel="stylesheet" type="text/css" href="/full-path-from-root-to/mystyle.css">
or
<link rel="stylesheet" type="text/css" href="http://example.com/full-path-from-root-to/mystyle.css">

Understand that example.com/controller/action refers to a page or object named "action" in the /controller directory, while example.com/controller/action/ refers to a directory index or index page in the /controller/action directory.

You should not think of these two URLs as "the same thing" and you should not allow these two URLs to both resolve to the same object, resource, or content. If there is some confusion in linking on your own site then fix it, and if there is some confusion in inbound links from other sites, then pick one or the other URL based on the page/directory selection criterion I described, and 301-redirect the "wrong" URLs to the right ones.

Be aware that any variation in http versus https, subdomain vs. domain, URL casing, trailing-slash vs. no-slash, or query string name/value pair presence and/or order will be treated by search engines as a separate URL. Make sure that any such variations are detected and 301-redirected to the single canonical URL for each object.

If you allow multiple URLs to resolve to the same content, then you have a duplicate-content problem: Two or more URLs competing for PageRank, link popularity, and resultant search ranking. While the major search engines run back-end de-duplication jobs on their URL databases to help with this problem, you cannot count on them to get through the enormous number of URLs on the Web in a timely manner, and you cannot count on them to pick the "right" URL for you if they do. Your pages' search rankings will be out of your control until you take steps to prevent duplicate content on your own server by canonicalizing all requested URLs.

We have discussed URL canonicalization here at length. My favorite thread title so far has been "Duplicate content - Get it right or perish."

Jim

[gargantuan]

Thanks Jim. That's a great answer.