Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.
One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.
About sessions, I think you might have to do session handling in your application itself. Often you get a session-ID from somewhere (Cookie, POST data or some URL parameter) and that will identify your session. If you have to create your own session ID's then use GUIDs, since they are very useful as unique identifiers...
Creating separate threads in a webserver is similar to creating threads in normal applications, although you have to be aware of the risk that your main thread might time-out before the other threads are finished. Creating child threads are therefor a bit risky since you might run out of resources. If you can avoid it, then don't use threads. The use of threads in web applications don't make much sense anyway since the webserver itself will run every request in it's own thread anyways.
For component use, use a WebModule or a data module. You won't be able to use visual components, though. Make sure that your components won't display some messageboxes or whatever since there will be no one available to click the [OK] button once it pops up. :-)
Sending data back to the client is not a real problem either. It's basic behaviour of the web module.
And about expiration... This too should be no problem since the module would just exist long enough to handle a single request before it is killed again. Keep in mind that webservers are stateless and thus every request you send to it will result in an action being started, it processes the incoming data, it generates the output and then the action is closed again! It won't continue to run until the next request...
It seems to me that you want some process to run in the background while a user is sending multiple requests to the server. To do this, you should actually split your project up in two parts. The first part is the web module which will be run from Apache. The second part should be a system service that will run in the background. Your webserver should talk to the system service, providing it the details about what it should do and the system service can run a thread for every session for the amount of time specified. The communication between system service and webserver can be done through named pipes, through TCP/IP and through many other inter-process communication tricks.
With a small amount of instances I would suggest that you start this project as a CGI application. It's easier to debug, although it might be slow if you have a huge amount of visitors. The advantage is that a CGI application is loaded every time a request is made and terminates when the request is done. An ISAPI DLL stays in memory after the first request and the only way to free it is by closing down the webserver. This means that every time you want to update the ISAPI DLL, you will have to stop the webserver, overwrite the DLL and then start the webserver...
Once your CGI application is working you can easily convert it to an ISAPI application if need be.