Question

Here is a typical URL I’m trying to rewrite:

Example requested URL:
http://topleveldomain/search?q=clause1+clause2+clause3&State=FL

It should rewrite to:
http://topleveldomain/index.cfm?q=clause1+clause2+clause3&State=FL

It sure does look simple enough, but the plus signs (and various query lengths) are giving me fits. I have written a few different Regex expressions that actually test out as having matched according to the URL Rewrite Module in IIS7, but when I apply the rule it doesn’t work. I’m certain the problem is in my Regex and not the expression of the replacement text (the rewritten URL with backreferences). The reason I know that is that I’ve tested a rewrite to a static URL with no backreference to the regex and it still does not work, even though it tests as a match according to the URL Rewrite admin app.

The number of clauses (and plus signs) could be as few as one up to infinity (or breakage, whichever comes first, haha).

Here is the most recent regex I wrote to match that URL. It’s the fourth or fifth regex I’ve written, all of which are showing matches in the URL Rewriter, but not matching in real practice.

search\?q=(\S+)&State=([a-z][a-z])$

It’s my desire to capture two backreferences:

1. The query string, or “q” which is what the user typed in the search box
2. The state value, which is what the user selected via an HTML SELECT form input

The method of data entry also seems not to matter, as I’ve tried both POST-ing and GET-ting the string data from the application and also by entering the URL into the browser.

Before you say something about the statecode regex, I realize my regex to match the two-letter state code is loose enough to allow invalid USA state codes — that’s not important because the URLs will be published from app/database values.

UPDATE: the failure of the regex pattern to match the input string from the browser is due to the question mark character in the URL being interpreted, whether it comes from the application (written as form submitting a GET) or if it’s just typed or pasted into the browser’s address bar.

Chalk it up to user error.

The regex after the question mark needs to be entered in the URL Rewrite [additional] Conditions box as a {Query_String} where it also accepts regex patterns.

IMO given the way that IIS/URL Rewrite parse the HTTP request, the test of a URL string which contains a question mark ought to throw an error or match with a disclaimer or warning.

Answer 1

What about:

^search\?q=([a-zA-Z0-9_+-]+)&State=([a-zA-Z]{2})$ index.cfm?q=$1&State=$2

That is, regex pattern:

search\?q=([a-zA-Z0-9_+-]+)&State=([a-zA-Z]{2})

Replacement:

index.cfm?q=$1&State=$2