Mod rewrite: inter-folder redirect breaks relative paths

How to create a redirect, that keeps the relative paths intact?

[cme_fi]

Hi,

I want to use nice URLs for my webpage. Consider a page contact.html to begin with. The .htaccess file in the same directory contains:

RewriteEngine On
RewriteRule contact$ contact/   [R]
RewriteRule contact/$ contact.html  [L]

Basic idea is to use www.mydomain.de/contact/ and redirect every misspelling or whatever to this URL. Two problems:

1) If I type www.mydomain.de/contact, the redirect to contact/ does not work, it shows the right page, but doesn't add the trailing slash.

2) If I open www.mydomain.de/contact/, it shows also the correct page, but the path is changed, such that stylesheets and images etc. can't be loaded if they're linked relatively. These relative paths are somehow important for me, so if there is a possibility to do so, please let me know.

Thanks in advance,

Chris

[jdMorgan]

> 1) If I type www.mydomain.de/contact, the redirect to contact/ does not work, it shows the right page, but doesn't add the trailing slash.

Sounds like you've got MultiViews enabled, which take precedence.

Try adding

Options -MultiViews

to your file.

The other problem is caused by the fact that relative paths are resolved by the client (browser or robot), so you must rewrite all cases of the incorrect URL to the correct URL, including the URLs for images and CSS. However, you need to get the appended-slash redirect working first before trying to fix this other problem.

Jim

[cme_fi]

Hi,

thanks a lot for helping me. However it was not the MultiViews option, I figured out that I forgot a [L] in the first rewrite rule, which caused that the second was also applied.

But this relative paths situation drives me a little bit crazy... For example if I want to link from the contact page to the product page, the relative link "product/" would end up at [domain.com...] instead of [domain.com...] which can be of course rewritten but looks very strange.

I wonder how other pages cope with these paths. I tried to define several links in an absolute way, which seems to work, but makes it hard to rename/move a directory and to have the page on a local webserver (where are some other pages, such that the root dir for the page gets "/mypage/" instead of "/". I'm looking forward to hear about your ideas.

Thanks,
Chris

[jdMorgan]

You can either use server-relative links, such as <a href="/products"> instead of <a href=products>, or you can rewrite all URLs starting with "/contact/" back to the root:

RewriteEngine on
RewriteRule ^contact$ /contact/ [R=301,L]
RewriteRule ^contact/$ /contact.html [L]
RewriteRule ^contact/(.+)$ /$1 [L]

Please understand that as I said above, it is the browser that resolves relative links.

If you use a page-relative link to "products" from the *page* example.com/contact, then the browser will resolve that to example.com/products

If you use a page-relative link to "products" from the *directory* example.com/contact/ or example.com/contact/contact.html, then the browser will resolve that to example.com/contact/products.

This is in compliance with the URL-resolution rules of HTTP/1.0 and HTTP/1.1. If you define that /contact is a subdirectory (by using the redirect rule above to externally redirect to /contact/), then all page-relative links will be resolved relative to that directory. So things are working as they are required to work.

The browser resolution rule is simple: Remove everything in the current page's URL past the last slash "/", and add the relative link to that. The result is the resolved relative link. Working through that rule with both your /contact and /contact URLs will show why the relative links are not working.

These rewrites do break your ability to test on a local PC that is not running a server. Only you can decide if the rewrite is "worth doing" because of this.

You may wish to use the page-relative linking form <a href="../products"> on your server, but that still does not help with testing on your local PC.

Jim

[edited by: jdMorgan at 6:13 pm (utc) on Dec. 6, 2006]