Can't do a status check

Nov 24, 2010 at 2:44 PM

I've successfully installed version 2.1 for IIS 6 with the MSI installer.  The ISAPI filter properties look ok in IIS (I got the "happy green arrow").  But I'm unable to do a status check in the browser.  Maybe I have the URL wrong.  I've tried http://localhost/iirfStatus.  I get "Bad Request (Invalid Hostname)."  I also get this when just trying http://localhost, or http://mydefaultsite.com/iirfStatus.  But my webserver works fine and is hosting several active websites. 

Any hints on how to do a successful status status check?

Thanks in advance,

Brian

Bad Request (Invalid Hostname)

Nov 24, 2010 at 2:54 PM

Also, I don't know where the logfile is.  Where should I look for this file?

Thanks,

Brian

Coordinator
Nov 24, 2010 at 4:22 PM
Edited Nov 24, 2010 at 4:23 PM

Your logfile location is configured in the iirf.ini file.    Look for the RewriteLog directive.  That specifies the "root name" of the logfile.  IIRF names its logfiles with the process ID of the worker process, so if your RewriteLog directive says "c:\temp\iirf" then the names of the generated Logfiles will be c:\temp\iirf_4211.log, and so on, where 4211 is the process id of w3wp.exe. Every time you get a new w3wp.exe (when Windows restarts, or when you stop and start IIS, etc) you will get a IIRF logfile.  To find the "current" logfile, you have to get the latest one by date, not the highest number.  (Windows hands out Process IDs in any old order).  Use Windows Explorer and sort by date. 

As for the IirfStatus URL, you need to have this feature turned on in the IIRF.ini file as well.  Strange that your requests are getting a hostname error. That is surprising.  I would be less surprised if you told me you were getting a 404 (not found) error - this would indicate that the StatusUrl directive is not used, or is used but is disabling the Iirfstatus URL.  Getting a hostname error suggests that IIRF is not receiving the request - in other words it's something more basic than IIRF configuration.  If this were true, then you should get the same hostname error whether you request http://localhost/IirfStatus or http://localhost/ThisDoesNotExist  or http://localhost .  Test that and see.   If you get a hostname error with http://localhost/IirfStatus but no hostname error with http://hostname, then I am at a loss - there is something mysterious going on.

Keep in mind that /Iirfstatus works only in virtual directories configured to use IIRF.  If you have no IIRF.ini file, you may not get an /Iirfstatus response.  also remember that by default /IirfStatus is restricted to local requests.  You can change this behavior with the StatusUrl directive.  Consult the documentation for more detail on that.

Good luck.

 

 

Nov 24, 2010 at 5:01 PM

Thanks for the detailed response, but let's back up a bit...

I have no iirf.ini file as far as I can tell - not in c:\inetpub and not in the virtual directory I set up with the MSI during install.  The only ini file I have is IirfGlobal.ini, located in C:\Program Files\Ionic Shade\IIRF 2.1.  It has only three directives:

  RewriteFilterPriority HIGH

  NotifyLog OFF

  RewriteEngine ON

So what I'm asking is about default behavior.  According to the docs, there should be a log file created by default.  Where is this?  Should I have any other ini files after my MSI installation?  I'm using /Iirfstatus only in the virtual directory.

However, after playing with this a bit, I did get the Status page.  I wasn't able to use localhost, but on the local machine, I used: http://subdomain.mydomain.com/iirstatus.  This only works on the server.  Here, subdomain is the virtual directory I mapped the website to, where I installed IIRF.  The status page tells me I have an ini file (Iirf.ini) in this virtual directory.  However, I checked, and no such file exists.  So it looks like I'm making progress, but why don't I see the Iirf.ini file?

Thanks,

Brian

 

 

 

Nov 24, 2010 at 5:02 PM

Or do I need to create the ini file in my virtual directory, and then the logfile will be created?

Thanks,

Brian