2

*) I have a Delphi XE ISAPI dll running under IIS 7.5 - Server 2008 R2. The DLL launches an instance of TISAPIApplication. The application resides at a discreet, fixed, predetermined URL, and listens on a particular port (not port 80) for requests - all of this is of course a 'standard configuration'.

*) On my server, I have several dlls, each launching a different instance of the TISAPIApplication, mapped to a different URL, and listening on a different port. At runtime, I distinguish between various instances of the application (Dev, Prod, FailOver etc) based on the port number (easier than parsing URL's).

*) I have looked around in the docs and source code of TISAPIApplication and its ancestor and associated classes, but I can't find anywhere a property that tells me on what port a particular instance of the application is listening - the port seems to be available only on a request by request basis. It seems to me that since in simple deployments the listening port is usually static, I should be able grab that port value on app startup - this will facilitate allocating certain resources then, instead of waiting for a request to come in, etc.

*) Anyone know how to do this? What property do I need grab, and from where? In fact, I can't find anything at all that will tell me anything about the URL the application itself resides at - everything seems to work on a per request basis.

( Please - I'm not looking for workarounds telling me how to do it via the request, or that HTTP is stateless and everything works on a per request basis - I know those workarounds and don't want to use them. And, although threads are spawned by ISAPI to handle requests in a 'stateless' manner, a TISAPIApplication instance is launched when the ISAPI dll is loaded by IIS and this TISAPIApplication instance persists througout the lifetime of the ISAPI application and contains state information that is valid for the lifetime of the application instance ).

TIA

Vector
  • 10,879
  • 12
  • 61
  • 101

2 Answers2

1

The ISAPI function GetServerVariable (http://www.podgoretsky.com/ftp/Docs/Internet/Late%20Night%20ActiveX/ch7.htm#CHttpServerContextObject - Table 7.7 HTTP Environment Variables) can return the SERVER_PORT variable. Maybe this function can be called when the DLL is initialized.

As you wrote

The application resides at a discreet, fixed, predetermined URL, and listens on a particular port (not port 80) for requests

and

At runtime, I distinguish between various instances of the application (Dev, Prod, FailOver etc) based on the port number

I assumed that you need to do something before the first request hits the app, like resource-consuming initialization tasks, instead of doing them with every request. In this case a function which can be used in an early stage of the application life cycle would be an advantage. However I did not do a research on the ISAPI application lifecycle to find out how this is usually done.

mjn
  • 36,362
  • 28
  • 176
  • 378
  • "Maybe this function can be called when the DLL is initialize" - yes, MAYBE - although from the looks of it, it's expecting data related to a request. Frankly, it's not important enough to go the trouble of wiring up everything needed to call that function only to discover that it doesn't work. :-) Thanks. – Vector Apr 04 '12 at 21:53
  • I think I'm going to close this question because I'm trying to do something here that isn't entirely valid: Even though simple apps generally have a listener sitting on a designated port that doesn't change, it doesn't have to be that way - the only way to determine the listening port with certainty is from the request itself, not before. – Vector Apr 04 '12 at 22:05
  • "...In this case a function which can be used in an early stage of the application life cycle would be an advantage." - yes, that's what's going on. The workaround I implemented is an old standard - first request in does the appropriate initialization and sets a flag that's it's been done. Flag is checked before making the calls - so subsequent requests will skip the initialiation code. – Vector Apr 05 '12 at 15:40
  • I think the answer I posted is the correct one - you really shouldn't be relying on a particular port at app initialization - but I'm not sure about all this - need to know more about ISAPI etc. Regardless, my workaround is fine - not the most elegant, but serves its purpose. – Vector Apr 05 '12 at 15:48
  • "did not do a research on the ISAPI application lifecycle to find out how this is usually done" - there is hook or two on TISAPIApplication where you can run code that's not request-centric. And in the DPR for the Delphi ISAPI app you can pretty much do anything you want in the way of initialization of resources, caches, etc. I did run into some trouble with using ADO in that context, but again it wasn't worth spending that much time on, because you can do everything with the flag workaround and the old Delphi trick of hanging things on unit variables that are outside of any classes, etc. – Vector Apr 05 '12 at 18:41
0

I think maybe I'm trying to do something here that isn't entirely valid: Even though simple apps generally have a listener sitting on a designated port that doesn't change, it doesn't have to be that way - the only way to determine the listening port with certainty is from the request itself, not before -so TISAPIApplication should not be persisting information about the listening port, which is essentially volatile.

Vector
  • 10,879
  • 12
  • 61
  • 101