Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Intraweb as windows service
1) You are still mixing up ports and IPs. IW can run on one IP on port 80 while IIS runs on another IP, still on port 80.

2) To register with HTTP.sys, you deploy as ISAPI or ASPX on IIS.

what Chad said about IP vs ports is that you can actually have one machine with 2 ip addresses. So, you can bind IIS to ip1, port 80 and your IW service to ip2, port 80 too. Or you can have IIS bind to both IPs. It is up to you.
However, if your machine has only one IP, only one application can bind to one specific port.
Thanks. I was not aware that if you configured the computer to have two IP addresses you could handle port 80 in two different applications.

But the whole point of HTTP.SYS is that you can have one IP address and multiple applications can all listen to port 80 on the same IP address.

I do not want to use IIS. I want to simply use Intraweb as a Windows Service.

From what I gather, aside from having the IT staff assign multiple IP address to the same PC, and then configuring my applications about which IP address each application is using, there is no way to share Port 80.

I am surprised that Indy/Intraweb does not provide a way to plug in to HTTP.Sys directly without using IIS. Indy seems to do everything else in the world Smile
http.sys is NOT needed at all. IW can be deployed as ISAPI, ASPX, or its own Indy based server (stand alone)

Please. For at least the third time.

IW by *default* will use port 80 on *all IPs* as does IIS. BOTH can be configured not to do this and to bind to only one or specific IPs. You can have IW on port 80 on one IP and IIS on another IP ALSO on port 80.

If you want to share port 80 on a single IP - Deploy IW as ISAPI or ASPX on IIS.
My requirements are

1. NO IIS. You keep saying over and over that I can use IIS, and I have said 2x at least that I do not have the option of IIS. So I will say it again, I NEED A SOLUTION THAT DOES NOT USE IIS.
2. The computer needs to have only a single IP address
3. I need to have multiple applications listening on port 80.

You keep saying HTTP.SYS is not required, and I can use IIS, even though I have said over and over that I do not want to use IIS for this application Smile

As far as I have read, HTTP.SYS is the only thing that would allow ALL of the above requirements to be fulfilled.

It is a shame that if I want to deploy multiple Intraweb applications on the same computer, listening to the same IP address, bound to the same port, that I need to use IIS. It would be very convenient if I could deploy multiple IW applications as windows services, all of them listening to port 80, without requiring multiple IP addresses.

If you could create a "project type" that plugged an intraweb app directly into HTTP.SYS that could deploy as a windows service, that would satisfy these requirements.

If you tell me to use IIS again, my brain may explode Smile
Use IIS (well, I don't but I've never seen an exploding brain before!)

Ok, more seriously.  As I understand, you said earlier that you want one app to listen to port 80 for some inbound URL's but have another listen to port 80 for other inbound URL's.

So, thinking about that, it requires some process (application) to figure out which URL is being called.  That can't happen on the "connect" to the port, the determination has to wait on data that comes after the port is connected because you simply don't know the target URL until after the connection.  

So, what happens is that one app must take over a port and listen.  THAT app can then do what it wants with the messages and connection.

The app connected to port 80 can accept whatever inbound connection comes, examine it, and then decide to redirect if some other app/server is supposed to handle it.  In any case, for a given IP and Port combination, only one app can have it.

If I misunderstood your requirements, I apologize so just use IIS.  <g>

If you're asking about redirecting to multiple servers then there are others here that do that and can answer.

Hi Dan,

Thanks for the response. Unless I can figure out otherwise, I will have to do as you suggest.

As of Windows Server 2003, Windows has a built in webserver called HTTP.SYS.

You call netsh http add and reserve a particular URL for your application. Then, windows forwards all http requests it gets to that URL to your application. 

Synopse has made a simple component that uses this to allow you to share port 80 among multiple applications without IIS.

It would be fantastic if one of the IW application types was to use HTTP.SYS directly. That way, you could have multiple intraweb apps, on the same server, with the same IP, all listening to port 80 without having the hassle of configuring IIS. Of course, IIS has other benefits if you need them, but applications with simple requirements, IIS is overkill.

I will do some research to see if there is a way to do this and report back if I find anything.
Currently http.sys as you request is not available and it would need to be added. It is the first request we have ever had for such as http.sys in this form has typically only been used for debugging and small internal deployments.

While it may be a good feature, with dev for 16 and 17 already in progress I don't know when it would fit into the short term dev roadmap.

By far, most customers who want to deploy in production use IIS as primary, with some using standalone service who prefer easy deployment.

Is this for an internal or external deployment? If it is internal, there is no need to use port 80 at all and you can simply use as many ports as you need. The only issue with using ports other than port 80 are outdated improperly configured proxies and firewalls.
I agree I may be making a strange app. It is a program that will allow university core facilities to manage their core facility. It will have a web front end using IW and the core facility will use it as a portal for their clients.

One of the requirements is to make the installation as simple as possible. The core facility should be able to simply install my software on a server and have it running. Several services need to run on the same computer. (web front end, REST services etc)

If the core facility has to deal with the the university IT staff to do anything sophisticated like: a) update and maintain their DNS to allow multiple IP addresses for the same computer, b) open multiple ports in their internal network for the same computer (with the proxy and firewall issues you allude to above), install and configure IIS etc it will be a huge impediment to uptake. University IT staff is notoriously slow, and one of the advantages I am giving them is that they can have a portal that they do not need to involve IT, or the university website people, to update.

I am presuming that in some way, a webserver is forwarding web requests to the IW server controller. Those requests are coming from IIS (for ISAPI) or from the INDY webserver (for standalone or windows service). I will see if I can figure out how to plugin that into one of the tools that also does direct HTTP.Sys connection, like TMS Sparkle or Synopse.

The only thing I can rely on is that usually (but not even always) port 80 is open in their network and that is the only thing I can use without a hassle.
Are you aware of what will happen to your application if it runs on port 80?!  You will need to implement your own security to handle all of the scanning and probing that will be directed at that port.  One of the benefits of IIS is that you can manage IP address restrictions and Request Filtering.

Port 80 will be scanned /probed every hour of every day.  You will need to capture and monitor that traffic.  If you don't, you will encounter performance issues for legitimate users.

Running on another port, such as 8080, will attract less traffic, but it still should be monitored.  Once a port is open security becomes the responsibility of the application on that port.  Running on the default port should not be taken lightly.

I've studied this over several years, and have the data to confirm it.  I have a security layer that gets baked into each IW application to manage this problem.  On any given day 30% of the traffic comes from probes and bots.  Without rejecting that traffic false sessions will be created that live until your timeout kicks in.  That can result in wasted resources and bad user experiences.

Forum Jump:

Users browsing this thread: 2 Guest(s)