Can anyone offer thoughts on issue: "Redirectrule with anchor in output clashes with case-folding option"

Topics: User Forum
Jun 16, 2011 at 4:32 PM
Edited Jun 16, 2011 at 4:33 PM

Hey folks, I reported an issue a couple of days ago (in the issue tracker, at I don't know how many people see that.

But in case someone reading here might have a thought (workaround or solution), I thought I'd point it out here. Hope that's ok. The topic is "Redirectrule with anchor in output clashes with case-folding option".

Bottom line: if you use a RedirectRule that has an anchor in its output string, it works fine until that anchor would start with a u or l or some other characters, which IIRF uses as "case folding" operators. I've tried all sort of escape options (see the issue notes for details).

If anyone may have already solved this, I'd really appreciate that help. Thanks.

Jul 1, 2011 at 11:31 PM

I'm hoping to bring this problem to someone's attention here. Someone else has now pinged in on the issue tracker that they have been hit by the same problem.

Jul 18, 2011 at 4:09 PM

Carehart - good catch.  Link to workitem 30847.

The problem you describe is real.  The case folding flag character # has multiple meanings - as you correctly point out it also is used to signal an anchor name in a target document.

The problem you describe will happen only when the anchor begins with one of the characters that is meaningful for case conversion: u, l, L, U, or E. 

I'd need to issue a fix to IIRF to get you beyond this problem.  I suppose the fix will be a new directive that allows you to specify a different flag character for case-conversion.

The workaround is to use anchor points that don't begin with those letters. 

Jul 18, 2011 at 4:45 PM

Thanks so much for looking into this. That fix sounds fine by me. As for the the anchors I have that start with those letters, changing them to work around this would be a fair challenge. I'll wait instead for what you may report about the prospects of a fix (whether it's easy or not, I mean). I'd hope it could be fixed, since it might reasonably affect others who might never even realize it. :-)

Again, thanks for giving it some consideration. I'll look forward to your next thoughts. Cheers.

Jul 19, 2011 at 12:38 AM

Hey carehart, I've posted some patched binaries on your workitem - one set for x86 and one set for x64.  Try it and see if it works for you. 

It allows you to use ## in the replacement string to emit a single #.  A relatively simple fix.  Everything else should work the same.

I also added a way to specify a different flag character - a new directive "FlagCharacters".  It takes 2 arguments, both characters.  The first is the RewriteCond back-ref character (Default *) and the second is the case-folding opcode character (Default #).  This new directive supercedes the CondSubstringBackrefChar directive. To use it, you would do something like this in your ini file:

FlagCharacters ~ @

Then, ~2 in a replacement string would refer to the 2nd substring in the most-recently evaluated RewriteCond, and @U..@E in the replacement string would upcase everything between the @U and the @E.