I’m trying to convert some simple .htaccess rewrites into web.config xml; all is well with most of them however I’m having particular problems with one which involves a query string.
Here is the .htaccess rule:
RewriteRule ^table/([a-zA-Z0-9\-_]+)/delete/([^/\.]+)$ table-index.php?mode=delete&type=$1&id=$2 [QSA,L]
Here is how I translated it:
<rule name="delete">
<match url="^table/([a-zA-Z0-9\-_]+)/delete/([^/\.]+)$" ignoreCase="true" />
<action type="Rewrite" url="table-index.php?mode=delete&type={R:1}&id={R:2}" appendQueryString="true" />
</rule>
Essentially, I did for this the same as I have with all of the other (working) rules, but this one is not playing ball. The only difference is that this rule has a [QSA] instruction in .htaccess which I translated to appendQueryString="true" for the XML.
The rule doesn’t break IIS, it just doesn’t work either – what should be showing as:
http://my.site/admin/table/mailing-list/delete/1?confirm=true
is showing as
http://my.site/admin/table-index.php?confirm=true
Which is missing quite a lot of vital information and causing things not to happen that should be happening… The same rule is functioning correctly when the URL doesn’t have the ?confirm=true query string in it.
Can anyone assist?
I had another look over this and found my own solution. There is nothing wrong the rewrite rule, rather, I was relying on an apache server variable in one of my links $_SERVER[‘REDIRECT_URL’] which IIS wasn’t providing, instead, $_SERVER[‘REQUEST_URI’] fixed it for me.
This wasn’t producing any errors because I’d already anticipated the event that the variable might not be given by some servers, and fallen back to another one – but that code was written in before I changed my system to work using rewritten URLs in the part of it that was causing the problem…!