Search code examples
url-rewritinghttprequestiis-6iirf

URL being stored in SCRIPT_NAME on subsequent requests in IIRF?


I'm having an issue with IIRF (Ionics Isapi Rewrite Filter) on IIS6 (although in this case not sure that's relevant), and it appears to be working on initial requests, but on a standard refresh (i.e. F5 not CTRL + F5), most of the time it will just 404. Although it appears to be intermittment. My re-write rule itself seems correctly, and I've tested it on various RegEx testers, as well as the fact it does work fine on a clear-cache refresh. I'm not an expert, but it appears to relate to the fact that on the times it doesn't work, the URL of the page I'm trying to hit is being fed through in the SCRIPT_NAME HTTP variable, rather than coming via the URL, which in this case appears to be the path I want to re-write to (although like I say, it 404's so it doesn't appear to actually be going to this path in these cases). I'm sure you'll see quite quickly that I'm just essentially doing extensionless URL re-writing. I've tried adding rules to re-write on the SCRIPT_NAME but no such luck so far.

My config is:

RewriteLog iirf
RewriteLogLevel 5
RewriteEngine ON 
IterationLimit 5

UrlDecoding OFF

# Rewrite all extensionless URLs to index.html 
RewriteRule ^[^.]*$ /appname/index.html

See the log below - this is a case of it NOT working. I'm hitting /appname/task/5 but it appears to store that in the SCRIPT_NAME. Strangely the URL it appears to want to re-write is actually the URL I want it to rewrite to.. Again, this is only on subsequent requests. On the first request it almost always re-writes without issue and page loads fine.

Tue Jul 12 10:17:33 -  4432 - Cached: DLL_THREAD_DETACH
Tue Jul 12 10:17:33 -  4432 - Cached: DLL_THREAD_DETACH
Tue Jul 12 10:17:33 -  4432 - HttpFilterProc: SF_NOTIFY_URL_MAP
Tue Jul 12 10:17:33 -  4432 - HttpFilterProc: cfg= 0x01C8CC60
Tue Jul 12 10:17:33 -  4432 - HttpFilterProc: SF_NOTIFY_AUTH_COMPLETE
Tue Jul 12 10:17:33 -  4432 - DoRewrites
Tue Jul 12 10:17:33 -  4432 - GetServerVariable_AutoFree: getting 'QUERY_STRING'
Tue Jul 12 10:17:33 -  4432 - GetServerVariable_AutoFree: 1 bytes
Tue Jul 12 10:17:33 -  4432 - GetServerVariable_AutoFree: result ''
Tue Jul 12 10:17:33 -  4432 - GetHeader_AutoFree: getting 'method'
Tue Jul 12 10:17:33 -  4432 - GetHeader_AutoFree: 4 bytes   ptr:0x000D93A8
Tue Jul 12 10:17:33 -  4432 - GetHeader_AutoFree: 'method' = 'GET'
Tue Jul 12 10:17:33 -  4432 - DoRewrites: Url: '/appname/index.html'
Tue Jul 12 10:17:33 -  4432 - EvaluateRules: depth=0
Tue Jul 12 10:17:33 -  4432 - GetServerVariable: getting 'SCRIPT_NAME'
Tue Jul 12 10:17:33 -  4432 - GetServerVariable: 16 bytes
Tue Jul 12 10:17:33 -  4432 - GetServerVariable: result '/appname/task/5'
Tue Jul 12 10:17:33 -  4432 - EvaluateRules: no RewriteBase
Tue Jul 12 10:17:33 -  4432 - EvaluateRules: Rule 1: pattern: ^[^.]*$  subject: /appname/index.html
Tue Jul 12 10:17:33 -  4432 - EvaluateRules: Rule 1: -1 (No match)
Tue Jul 12 10:17:33 -  4432 - EvaluateRules: returning 0
Tue Jul 12 10:17:33 -  4432 - DoRewrites: No Rewrite

Any help is much appreciated!

Thanks


Solution

  • I'm not sure what the reason for it being stored in the SCRIPT_NAME variable was, but I've written an extra rule to cater for it, which fixed it for me:

    RewriteEngine ON
    IterationLimit 5
    UrlDecoding OFF
    
    # Rewrite all extensionless URLs to index.html 
    RewriteRule ^[^.]*$ /appname/index.html
    
    # Subsequent requests may store the URL in the SCRIPT_NAME variable for some reason
    RewriteCond %{SCRIPT_NAME} ^[^.]*$ # If SCRIPT_NAME variable contains an extensionless URL
    RewriteRule .*\S.* /appname/index.html [L] # Rewrite all URLs to index if RewriteCond met