incorrect physical path

Topics: User Forum
Aug 30, 2008 at 10:31 PM
I'm using your filter to redirect a subdirectory on one virtual server to the root of another virtual server. I'm having an issue with the output physical path. These are the rules I have:

RewriteRule ^/intranet   http://intranet.website.com
RewriteRule ^/intranet/   http://intranet.website.com/

The filter is installed on a virtual server called 'remote', so a request for 'http://remote.website.com/intranet' is successfully matching and being redirected to 'http://intranet.website.com'.

See the log:

Sat Aug 30 15:55:53 2008 - HttpFilterProc: SF_NOTIFY_URL_MAP
Sat Aug 30 15:55:53 2008 - OnUrlMap: storing physical path (c:\inetpub\wwwroot\intranet), in ptr (0x000b5350)
Sat Aug 30 15:55:53 2008 - HttpFilterProc: SF_NOTIFY_AUTH_COMPLETE
Sat Aug 30 15:55:53 2008 - DoRewrites
Sat Aug 30 15:55:53 2008 - GetServerVariable_AutoFree: getting 'url'
Sat Aug 30 15:55:53 2008 - GetServerVariable_AutoFree - no joy (GetLastError()=1413)
Sat Aug 30 15:55:53 2008 - GetServerVariable_AutoFree: 128 bytes
Sat Aug 30 15:55:53 2008 - GetServerVariable_AutoFree: result ''
Sat Aug 30 15:55:53 2008 - GetHeader_AutoFree: getting 'url'
Sat Aug 30 15:55:53 2008 - GetHeader_AutoFree: 10 bytes
Sat Aug 30 15:55:53 2008 - GetHeader_AutoFree: result '/intranet'
Sat Aug 30 15:55:53 2008 - GetServerVariable_AutoFree: getting 'QUERY_STRING'
Sat Aug 30 15:55:53 2008 - GetServerVariable_AutoFree: 1 bytes
Sat Aug 30 15:55:53 2008 - GetServerVariable_AutoFree: result ''
Sat Aug 30 15:55:53 2008 - GetHeader_AutoFree: getting 'method'
Sat Aug 30 15:55:53 2008 - GetHeader_AutoFree: 4 bytes
Sat Aug 30 15:55:53 2008 - GetHeader_AutoFree: result 'GET'
Sat Aug 30 15:55:53 2008 - DoRewrites: New Url: '/intranet'
Sat Aug 30 15:55:53 2008 - ApplyRules: depth=0
Sat Aug 30 15:55:53 2008 - ApplyRules: Rule 1 : 1 matches
Sat Aug 30 15:55:53 2008 - ReplaceServerVariables: InputString='http://intranet.website.org' out='http://intranet.website.org'
Sat Aug 30 15:55:53 2008 - GenerateReplacementString: src='/intranet','(null)' ReplacePattern='http://intranet.website.org' vec=[[  0, 9] [] ] counts=1,0
Sat Aug 30 15:55:53 2008 - ApplyCaseConversion: before 'http://intranet.website.org'
Sat Aug 30 15:55:53 2008 - ApplyCaseConversion: after  'http://intranet.website.org'
Sat Aug 30 15:55:53 2008 - GenerateReplacementString: result 'http://intranet.website.org'
Sat Aug 30 15:55:53 2008 - ApplyRules: Result (length 26): http://intranet.website.org/
Sat Aug 30 15:55:53 2008 - ApplyRules: depth=1
Sat Aug 30 15:55:53 2008 - ApplyRules: Rule 1 : -1 (No match)
Sat Aug 30 15:55:53 2008 - ApplyRules: Rule 2 : -1 (No match)
Sat Aug 30 15:55:53 2008 - ApplyRules: returning 0
Sat Aug 30 15:55:53 2008 - ApplyRules: returning 1
Sat Aug 30 15:55:53 2008 - DoRewrites: Rewrite Url to: 'http://intranet.website.org'
Sat Aug 30 15:55:53 2008 - DoRewrites: not recording OriginalUrl (0x001221d8)
Sat Aug 30 15:55:53 2008 - DoRewrites: Finished
Sat Aug 30 15:55:53 2008 - HttpFilterProc: SF_NOTIFY_URL_MAP
Sat Aug 30 15:55:53 2008 - OnUrlMap: storing physical path (c:\inetpub\wwwroothttp:\intranet.website.org), in ptr (0x00105258)

The problem is on the second line of the log. That physical path does not exist. 'http://remote.website.org/intranet' is physically located at 'c:/inetput/intranetdummy' BUT I am getting the same results whether or not the virtual directory '/intranet' actually exists on 'remote', since the rewrite is being done before IIS even tries to access that location. As you can see, this messes up the last line of the log.

Is there some reason that IIS is not looking up the new URL and is just assuming its location? Because the actual location of 'http://intranet.website.com' is 'c:\Inetpub\wwwroot\wss\VirtualDirectories\intranet80'.

I am hoping there is a way to make IIS look up the site on the other server WITHOUT doing a browser redirect. I think this was working before...

'remote' and 'intranet' are on the same physical server and I have tried moving the filter up to cover the entire server. That might fix it too, but when I do that, the filter shows to be online but no log file ever shows up and the rewriting never happens, even after restarting IIS.

Thanks in advance for any ideas.

-neka
Aug 30, 2008 at 10:45 PM
okay....I got the filter to work running on the whole server. I guess it was just taking a bit to get moving. I had only tried it about 30 seconds or so after an IIS restart. After writing the last post though I had three log files running for all the servers and rewriting was working...or, back to not working, depends on your view. The log didn't change any that I can tell.

Sat Aug 30 16:37:44 2008 - HttpFilterProc: SF_NOTIFY_URL_MAP
Sat Aug 30 16:37:44 2008 - OnUrlMap: storing physical path (c:\inetpub\wwwroot\intranet), in ptr (0x000b59f0)
Sat Aug 30 16:37:44 2008 - HttpFilterProc: SF_NOTIFY_AUTH_COMPLETE
Sat Aug 30 16:37:44 2008 - DoRewrites
Sat Aug 30 16:37:44 2008 - GetServerVariable_AutoFree: getting 'url'
Sat Aug 30 16:37:44 2008 - GetServerVariable_AutoFree - no joy (GetLastError()=1413)
Sat Aug 30 16:37:44 2008 - GetServerVariable_AutoFree: 128 bytes
Sat Aug 30 16:37:44 2008 - GetServerVariable_AutoFree: result ''
Sat Aug 30 16:37:44 2008 - GetHeader_AutoFree: getting 'url'
Sat Aug 30 16:37:44 2008 - GetHeader_AutoFree: 10 bytes
Sat Aug 30 16:37:44 2008 - GetHeader_AutoFree: result '/intranet'
Sat Aug 30 16:37:44 2008 - GetServerVariable_AutoFree: getting 'QUERY_STRING'
Sat Aug 30 16:37:44 2008 - GetServerVariable_AutoFree: 1 bytes
Sat Aug 30 16:37:44 2008 - GetServerVariable_AutoFree: result ''
Sat Aug 30 16:37:44 2008 - GetHeader_AutoFree: getting 'method'
Sat Aug 30 16:37:44 2008 - GetHeader_AutoFree: 4 bytes
Sat Aug 30 16:37:44 2008 - GetHeader_AutoFree: result 'GET'
Sat Aug 30 16:37:44 2008 - DoRewrites: New Url: '/intranet'
Sat Aug 30 16:37:44 2008 - ApplyRules: depth=0
Sat Aug 30 16:37:44 2008 - ApplyRules: Rule 1 : 1 matches
Sat Aug 30 16:37:44 2008 - ReplaceServerVariables: InputString='http://intranet.website.org' out='http://intranet.website.org'
Sat Aug 30 16:37:44 2008 - GenerateReplacementString: src='/intranet','(null)' ReplacePattern='http://intranet.website.org' vec=[[  0, 9] [] ] counts=1,0
Sat Aug 30 16:37:44 2008 - ApplyCaseConversion: before 'http://intranet.website.org'
Sat Aug 30 16:37:44 2008 - ApplyCaseConversion: after  'http://intranet.website.org'
Sat Aug 30 16:37:44 2008 - GenerateReplacementString: result 'http://intranet.website.org'
Sat Aug 30 16:37:44 2008 - ApplyRules: Result (length 26): http://intranet.website.org
Sat Aug 30 16:37:44 2008 - ApplyRules: depth=1
Sat Aug 30 16:37:44 2008 - ApplyRules: Rule 1 : -1 (No match)
Sat Aug 30 16:37:44 2008 - ApplyRules: Rule 2 : -1 (No match)
Sat Aug 30 16:37:44 2008 - ApplyRules: returning 0
Sat Aug 30 16:37:44 2008 - ApplyRules: returning 1
Sat Aug 30 16:37:44 2008 - DoRewrites: Rewrite Url to: 'http://intranet.website.org'
Sat Aug 30 16:37:44 2008 - DoRewrites: not recording OriginalUrl (0x000a6fd0)
Sat Aug 30 16:37:44 2008 - DoRewrites: Finished
Sat Aug 30 16:37:44 2008 - HttpFilterProc: SF_NOTIFY_URL_MAP
Sat Aug 30 16:37:44 2008 - OnUrlMap: storing physical path (c:\inetpub\wwwroothttp:\intranet.website.org), in ptr (0x000ee580)

Its just pulling the first path out of thin air or something...apending the URL to the root I guess. It wasn't doing that the other day, but I don't know what has changed.  -thx
Coordinator
Sep 3, 2008 at 8:36 PM
I am not sure what you are asking, but I can make some observations.

You are not doing a Redirect.  You wrote that you are doing a redirect, but that is done with a [R] flag, which you do not use.
Therefore, your rules are doing rewrites.  Check the readme for more info.

Next, you talked about something getting "messed up in your logfile".  Or something.  The logfile is just an indicator of what the filter is doing.  Nothing appears to be messed up in it.  It is just telling you what your rules are doing. 

Finally, you have some comment about the existence of a directory, either on the local server or on the remote server, I am not sure.  I'm not really clear on what the issue is there, but maybe take care of the first item above, and then we can deal with the existence of the directory.