Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Pages: 1
#1 2008-03-25 04:15:42
- cameroooon
- New Member
- From: Melbourne, Australia
- Registered: 2008-03-24
- Posts: 3
Clean URLs using IIS Mod-rewrite
I’m attempting to enable clean urls on a Textpattern site hosted in a Windows 2003 Server environment.
In an effort to mimic Apache’s mod-rewrite capabilities I’ve installed a product called ‘IIS Mod-rewrite’ produced by Micronovae. (We’re on a dedicated hosting agreement, so to some extent we’re able to tweak the server environment as necessary.)
IIS Mod-rewrite appears to do 90% of what Apache’s mod-rewrite module can, however I’m very new to the whole mod-rewrite thing and was hoping someone might be able to help fill the gaps.
The IIS Mod-rewrite documentation says that [E=var:val] will not work, so the RewriteRule .* – [E=REMOTE_USER:%{HTTP:Authorization}] is not being heeded. I’ve searched around for information about what this line actually does, but haven’t been able to uncover anything definitive.
Having said this, using IIS Mod-rewrite and the default .htaccess settings I am able to view clean URLs. However the only page that is being served (under any ‘section/title’ URL combination) is ‘index.php’.
Is this likely to be the result of failing to set the REMOTE_USER variable?
Moving on (hesitantly) from .htaccess… my reading thus far leads me to think that the page interpretation process goes something like:
————————-
1. A page request for ‘http://www.abc.com/section/title’ is sent to the server.
2. The mod-rewrite rules examine this URL, and because of it’s structure, sends the page off to index.php to be parsed (while still retaining the ‘http://www.abc.com/section/title’ URL).
3. The magic of Textpattern’s ‘index.php’ page then somehow maps the clean URL structure to the appropriate content and serves the completed page back to the browser.
————————-
Is that in the ball park?
If so… any suggestions why Textpattern isn’t quite performing step 3 as expected, and any possible work-arounds?
Many thanks!
Offline
#2 2008-03-25 22:32:30
- cameroooon
- New Member
- From: Melbourne, Australia
- Registered: 2008-03-24
- Posts: 3
Re: Clean URLs using IIS Mod-rewrite
After liaising with the support team at Micronovae a solution was found by simply adding the following line straight after the opening “<?php” directive in index.php:
$_SERVER[‘REQUEST_URI’] = $_SERVER[‘HTTP_X_ORIGINAL_URL’];
I’m not sure that it’s appropriate to post direct links to 3rd party suppliers, so to find out more info on this head to Google and do a search on the code above… there’s a page on the Micronovae site explaining how it works. Further research on the site will give you product information and pricing and help you decide whether or not it is a suitable solution for you.
Just to re-iterate… this approach worked for us because we use a dedicated server and can install software as we require. If you are on a shared Windows hosting environment you’ll need to find out from your web host company if they are willing to install such mod-rewrite software for IIS.
Hope that all helps someone out there!
Offline
#3 2008-03-25 23:29:26
- Mary
- Sock Enthusiast
- Registered: 2004-06-27
- Posts: 6,236
Re: Clean URLs using IIS Mod-rewrite
That line isn’t for clean urls. It’s for getting the password_protect tag to work on setups without mod_apache. :)
Offline
#4 2008-03-26 04:07:30
- cameroooon
- New Member
- From: Melbourne, Australia
- Registered: 2008-03-24
- Posts: 3
Re: Clean URLs using IIS Mod-rewrite
Thanks Mary! Any chance you could elaborate? What’s the relationship between enabling the password_protect tag and having clean URLs work?
Offline
#5 2008-03-26 22:53:01
- Mary
- Sock Enthusiast
- Registered: 2004-06-27
- Posts: 6,236
Re: Clean URLs using IIS Mod-rewrite
password_protect uses the variables $_SERVER['PHP_AUTH_USER']
and $_SERVER['PHP_AUTH_PW']
, which exist with mod_php, but not with (f)cgi. So, the tag also tries to use $_SERVER['REDIRECT_REMOTE_USER']
coupled with those .htaccess lines as a workaround. Their purpose is to feed the variable $_SERVER['HTTP_AUTHORIZATION']
into the REMOTE_USER
environment variable.
Offline
Pages: 1