IIRF 2.1.1.14 fails (oh, wait, no it doesn't)

Apr 29, 2010 at 9:13 PM

Cheeso, I tried to upgrade my install from 2.1.1.3 to 2.1.1.14 and it will not load

Event viewer shows an application error:

Event Type:    Error
Event Source: W3SVC-WP
Event Category: None
Event ID: 2214
Date: 4/29/2010
Time: 3:02:25 PM
User: N/A
Computer: myhost
Description:
The HTTP Filter DLL C:\Program Files\Ionic Shade\IIRF2.1\bin\IIRF.dll failed to load. The data is the error.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 7e 00 00 00 ~... 

This seems to indicate that a specified module cannot be found.  I renamed iirf.dll and pasted in the dll from 2.1.1.3 in again, and it started working fine, so it's not permissions.


Coordinator
Apr 29, 2010 at 11:06 PM

Hmmm,

can you try a depends.exe on that 2.1.1.14, and compare it to the depends.exe output for v2.1.1.3 ? 

Apr 30, 2010 at 1:52 AM

Arrghh, never mind, I substituted 2.1.1.14 back in and now it's working.  But I'm getting some strange results.  Are you sure that RewriteBase is working as expected in 2.1.1.14?  I started getting 404 errors, and I noticed that the output URL was missing the leading "/" (my application is at the root).

I was also trying to add a very simple rule to 2.1.1.3, and it wasn't working as expected:

RewriteRule ^/Shibboleth\.sso - [L]

Basically, I don't want any url of the form "http://myhost/Shibboleth.sso/<anything>" to be rewritten.  This is to allow for my shibboleth authentication process.  I added this rule as the first rule in the local ini file.

Strangely, the url "http://myhost.com/Shibboleth.sso/Metadata" would never match that rule (I checked the logs and the URL was coming in as "/Shibboleth.sso/Metadata" as expected)!  Am I overlooking something obvious? 

I'll be doing more testing in the morning.

Coordinator
Apr 30, 2010 at 4:19 PM

Hey Randy,

The RewriteBase is relatively new, so... no, I am less confident in the correctness of that feature.

It does change behavior in what can be surprising ways.  For example, If you turn RewriteBase ON, and you're working in the root directory, then it strips the leading slash from the URL that is checked in each pattern.   If you're working in a sub-directory, then it strips the vdir root path, including the trailing slash, from the URL that is checked in each pattern.

If you have patterns that check for ^/.* , or anything that begins with a ^/, then ... those patterns won't match, when RewriteBase is ON.  

Specifically, if you have

RewriteBase ON
RewriteRule ^/Shibboleth\.sso - [L]

...that rule will never fire.

That is true, unless you explicitly override RewriteBase with a specific value.  I don't recommend this, but it's included in the tool for compatibility with Apache mod_rewrite.

ok, now beyond the pattern matching, RewriteBase causes the base to be prefixed to any rewrite result, after the replacement.  Once again, this includes the trailing slash in the base, though IIRF will not produce double-slashes in the vdir root. 

So, if you have

RewriteBase ON
RewriteRule ^Something/(.*)$   /Another/$1 [L]

...and this occurs in the root, where the base is "/", then you will not get a doubled slash in the replacement.  And, because with RewriteBase ON, the URL base is prepended to the result of the rewrite, there's no way to rewrite to a URL outside of the current vdir, with RewriteBase ON.

These behaviors can be surprising, because they're implicit, and not specifically visible in the rules themselves.

Apr 30, 2010 at 4:20 PM

Ok, I think I've got a handle on what's going on, and there's 2 separate issues to discuss.  I'll break those out into  2 separate discussions.

Coordinator
Apr 30, 2010 at 4:50 PM

just looked at the code again.  I think you're right, it's not correct, especially when dealing with - replacements.