I want to remove trailing dots such as ... from all urls on IIS. I tried to use the following rule:
<rule name="RemoveTrailingDots" stopProcessing="true">
<match url="^([^.]*)\.+$" />
<action type="Redirect" redirectType="Permanent" url="{R:1}" />
</rule>
This works as expected on my local PC but not on my website.
For example I expected /fruits/apple... to be redirected to /fruits/apple but no redirect happens.
Thanks
Your problem is you're requiring that everything before the trailing dots be completely devoid of dots. You might try something like
<match url="^(.*[^.])\.+$" />
This will match any number of characters, followed by a single non-dot character (as part of the capture), followed by dots (which aren't captured).
That said, I don't understand why you even want this. URLs with trailing dots are not even remotely a common thing to have.
Related
I'm trying to make a IIS redirect rule to redirect from this url pattern, but it beats me:
https://www.mycompanyPLC.com/en/lorem/ipsum/whatever
to
https://www.mycompanyLTD.com/lorem/ipsum/whatever
Basically I need to replace PLC with LTD and if there is the "/en/" group in url, this has to be removed.
You can achieve your both the requirements using the single regex provided /en/ is preceded by .com. Something like:
(.*?)PLC\.com(?:\/\ben\b)?(.*)
Explanation of the above regex:
(.*?) - Represents 1st capturing group capturing everything before PLC lazily.
PLC\.com - Matches PLC.com literally.
(?:\/\ben\b)? - Represents a non-capturing group matching \en literally zero or one time. \b represents a word boundary.
(.*) - Represents the second capturing group matching everything after \en greedily.
$1LTD.com$2 - For the replacement(or redirection in this case) part you can get away with this string where $1 represents the first captured group and $2 represents the second captured group. In your case; you can use {R:1}LTD.com{R:2}.
You can find the demo of the above regex in here.
Please refer to below URL rule.
<system.webServer>
<rewrite>
<rules>
<rule name="ReverseProxyInboundRule1" stopProcessing="true">
<match url="en(.*)" />
<action type="Redirect" url="https://www.mycompanyLTD.com{R:1}" />
</rule>
</rules>
</rewrite>
</system.webServer>
There is no need to match a /en URL fragment forcibly. We redirect the request as long as we found that we have a /en URL segment. so does the http/https URL segment.
Feel free to let me know if there is anything I can help with.
After several hours of lecturing Regex I've created this rule and seems to be working (I've tested several scenarios):
^(http|https)://?(www.)mycompanyPLC.com/en?(.*)
and the Redirect URL from IIS is:
https://www.mycompanyLTD.com/{R:3}
Later edit:
The rule in IIS is like this:
<rule name="Replace PLC with LTD and remove /en/" enabled="true" stopProcessing="true">
<match url="(.*?)PLC\.com(?:\/\ben\b)?(.*)" />
<conditions logicalGrouping="MatchAny" trackAllCaptures="false" />
<action type="Redirect" url="{R:1}ltd.com{R:2}" />
</rule>
Test urls were this format:
http://webdev.myCompanyplc.com/en/our-experience/retail
{R:1} = http://webdev.myCompany
{R:2} = /our-experience/retail
Regex expression was ok, but redirect still didnt work
I'm have the following link
https://example.com/myapp/green?&lang=en&instance=some%20instance
I need to rewrite it to the following link
https://example.com/myapp?color=green&lang=en&instance=some%20instance
The color in the link can be any color but it needs to be rewritten like in the 2nd link so that the trailing slash is replaced with a ? followed by the word color= and the ? at the end of the color word needs to be removed.
/myapp/green? becomes /myapp?color=green,
/myapp/blue? becomes /myapp?color=blue
and so forth, all while keeping the rest of the query string &lang=en&instance=some%20instance intact
I've tried regexing my way out of this but I usually catch everything or unintentionally omit the rest of the query string.
Any ideas on what's the best approach?
EDIT: noticed that IIS, when applying to application level (not website level), the input URL path is after '/myapp/' and I need that trailing slash removed. Does this mean I'll have to apply it to the website level?
You could use below url rewrite rule(add this rule at site level):
<rule name="color query" enabled="true" stopProcessing="true">
<match url="myapp/(.*)/$" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false">
<add input="{QUERY_STRING}" pattern="lang=(.*)&instance=(.*)" />
</conditions>
<action type="Redirect" url="http://www.sample1.com/myapp?color={R:1}&lang={C:1}&instance={C:2}" appendQueryString="false" />
</rule>
Note: you could not remove the myapp/ from URL it will be added automatically in URL.
Server: IIS 8
I have a URL Rewrite rile to redirect PDF files to a page that will handle some additional processing. Everything works good except when the PDF files have special characters or spaces in them, then the destination page only gets the characters right of any spaces or special characters.
As an example, see the following filename:
Receipt - Hard Drive.PDF
the receiving page (/getfile/?PDF=) would receive only
Drive.PDF
I have tried various regex methods but as with most people my regex knowledge is pretty terrible.
How can I write a 'match URL' that will accept all filenames (at least those accepted by Windows, such as filenames with underscores, dashes, spaces, single quotes, double quotes, pound signs, etc). Is there any way to write something universal that simply passes all characters regardless of what they are, since I really only want to match *.pdf? My current rule is below.
<rule name="PDF Rewrite" stopProcessing="true">
<match url="([\w-]+)\.pdf$" />
<action type="Redirect" url="/getfile/?PDF={R:1}.pdf" logRewrittenUrl="true" redirectType="Temporary" />
</rule>
You may use
<match url="(.+)\.pdf$" />
The .+ matches one or more characters other than line break chars as many as possible.
I'm replatforming an online shop, and part of that process is writing 301 redirects for old links customers may have bookmarked to hit their new addresses. All of them work apart from the ones in which the old address contains the % character. It seems to somehow be interfering with the regex. The rule is:
<rule name="Custom 41 redirect" stopProcessing="true">
<match url="^c80/How-to-%20Use-Shop-Name\.aspx" ignoreCase="true" />
<action type="Redirect" url="/how-to-use-shop-name" redirectType="Permanent" />
</rule>
Testing using the built in regex tester in IIS tells me that hitting
/c80/How-to-%20Use-Shop-Name.aspx
Matches the pattern, yet the rule fails to redirect me when I hit that address.
I should also stress that there are about 400 rewrites in my web.config, but only the 3 which contain the % character break.
Since the string that is tested against the regex is already Url-decoded, you no longer need the %20 in your regex. Just use a plain space:
<match url="^c80/How-to- Use-Shop-Name\.aspx" ignoreCase="true" />
Also, in case the space is optional, you may use a ? after it:
<match url="^c80/How-to- ?Use-Shop-Name\.aspx" ignoreCase="true" />
I'm using Mod Rewrite for IIS 7.0 from iis.net and want to redirect requests:
http://example.com/users/foo to http://example.com/User.aspx?name=foo
http://example.com/users/1 to http://example.com/User.aspx?id=1
I have created 2 rules:
<rule name="ID">
<match url="/users/([0-9])" />
<action type="Rewrite" url="/User.aspx?id={R:1}" />
</rule>
<rule name="Name">
<match url="/users/([a-z])" ignoreCase="true" />
<action type="Rewrite" url="/User.aspx?name={R:1}" />
</rule>
It passes a test into iis mmc test dialog, but doesn't in debug (URL like http://localhost:9080/example.com/users/1 or …/users/foo) and doesn't on real IIS!
What have I done wrong?
The obvious problem is that your current regexes only match one character in the user name or one number. You'll need to add a plus quantifier inside the parentheses in order to match multiple letters or numbers. See this page for more info about regex quantifiers. Note that you won't be matching plain URLs like "/users/" (no ID or name). Make sure this is what you intended.
The other problem you're running into is that IIS evaluates rewrite rules starting from the first character after the initial slash. So your rule to match /users/([0-9]) won't match anything because when the regex evaluation happens, the URL looks like users/foo not /users/foo. The solution is to use ^ (which is the regex character that means "start of string") at the start of the pattern instead of a slash. Like this:
<rule name="ID">
<match url="^users/([0-9]+)" />
<action type="Rewrite" url="/User.aspx?id={R:1}" />
</rule>
<rule name="Name">
<match url="^users/([a-z]+)" ignoreCase="true" />
<action type="Rewrite" url="/Users.aspx?name={R:1}" />
</rule>
Note that you're choosing Users.aspx for one of these URLs and User.aspx (no plural) for the other. Make sure this is what you intended.
BTW, the way I figured these things out was by using IIS Failed Request Tracing to troubleshoot rewrite rules. This made diagnosing this really easy. I was able to make a test request and look through the trace to find where each rewrite rule is being evaluated (it's in a section of the trace called "PATTERN_MATCH". For the particular PATTERN_MATCH for one of your rules, I saw this:
-PATTERN_MATCH
Pattern /users/([0-9]+?)
InputURL users/1
Negate false
Matched false
Note the lack of the beginning slash.
You should use <match url="/users/([0-9]+)" /> and <match url="/users/([a-z]+)" ignoreCase="true" />, respectively, to match the complete id/user and not just their first letter/digit. But I don't know why your regex would have failed on a single digit, so there must be another issue, too.
As for your second question, I'm not sure I understand completely. How can you tell the difference between a folder name and a user name? Will a folder always have a trailing slash?