Standalone web server versus Apache / IIS

Question

I am developing a rather complex application with win32 and web access. Server-side implementation is a common occurrence, and it will be hosted by our company. An HTTP server can be implemented as a separate Indy (or other) HTTP server, or more traditionally with Apache / IIS.

I would like to know what are the advantages / disadvantages of a standalone HTTP server and Apache / IIS in terms of security or anything that you consider relevant.

Answer 1

I would say it depends on your needs and expectations. It makes a big difference if you write a custom simple http server, perhaps even ISAPI support, etc., Or you write a highly specialized http server / proxy server, etc., which limits only narrow specialized tasks. For example, I have such a specialized proxy server and a specialized infrastructure for processing ISAPI modules. Not many benefits I would say. So, professionals:

• Easy to deploy. Try deploying apache with your application to each machine.
• Better performance, less memory footprint. Try using apache on low-maintenance laptops.
• Increased security. Since you perform only narrow tasks, the probability of violation is much less. Apache does everything possible, so the probability of violation is much higher.
• Full control over the operation of such a server and control over the code. If you need a slightly different behavior or new features, you got it.
• If you use ISAPI modules like me, you can isolate them in separate processes and achieve greater stability. If one module / request fails, the others will not suffer.

Vs:

• Writing another http server
• Learning protocols and internal operations from scratch
• The more errors, the higher the probability of errors, because the code has not yet hardened. It takes time to settle.
• Since you have a narrow focus, you are not as universal as Apache for comparison. Not necessarily bad, as stated earlier.

My verdict will be like that. If you need a simple HTTP server to serve some content, and you will host it in your home, on one or more servers, for Apache. If you are creating a specialized part of the processing of http code that will be installed a lot, and you will need to control it, then develop your own. Believe me, it's worth it. I am so glad that then I stuck to this when we decided the same thing. Now I have many computer software installations, which is rather complicated, and I can’t imagine that I need to install Apache on every laptop. And then configure it as I need.

And Indy (with all its problems and quirks) turned out to be very stable out of the web server box. ICS is probably the same here, but I have not used it for this yet, so I can not say. Setting up Indy's HTTP server is ridiculous.

Only my two cents;)

Answer 2

By "stand-alone web server" do you mean embedded in your application? I have never used Indy, but I have been working on several Java applications using the Jetty library. The main advantages of this compared to the Apache / IIS proxy on the application server are its easier deployment and configuration, since the web service is tightly integrated into the application and you do not need to install anything.

If you have existing applications and this new application is allowed to be deployed in the same environment, I am sure that your sys administrators will want to use the existing application server. No one requires additional operational complexity, even if it’s a little easier for you to build. Adding another application to the application server is trivial.

Other considerations:

Security: network configuration, log files, access controls, etc. will have different implementations from your Apache / IIS systems, while others usually mean worse security. Simple things, such as SSL authentication, which sys administrators understand with Apache / IIS, will work differently with the built-in web server.

Performance: the embedded server is probably a bit more efficient, but a bit less scalable. Your coding decisions have a big impact on this, and with built-in servers it's easy to screw it up.

Development. I find that embedded servers are much easier to work with, as I can run them as simple Java applications instead of web applications, for example. Java Eclipse view instead of J2EE view with Tomcat integration.

I know this is an answer from a Java perspective, but I hope the general ideas apply to Delphi.

Answer 3

IIS and Apache are well versed in http servers.

The only advantage to having your own HTTP server is to simplify the deployment, which probably will not be an advantage, assuming that the server side of your application will be hosted exclusively in your company.

Another benefit might be performance, you could achieve higher bandwidth and better response time with a configured http server. But apart from ease of deployment and performance, I see no other advantage.

There are many disadvantages though

• you write already written code
• you will need to justify and explain to new developers why IIS and Apache are not suitable
• you will need to document and train others how to use such an http server. for example, new developers should know how to configure an SSL certificate or GZIP compression on IIS / Apache, however, they will need to find out from you how to do this on your http server, and regardless of whether it supported this function at all
• If this is your first http server for recording, you will need to spend a lot of time studying and studying the various standards and conventions that are outside of your main business domain that your application is aimed at.

Answer 4

I usually develop as a stand-alone, so I get the best debugging testing, and then deploy as an ISAPI DLL.

Answer 5

I had several cases when I also asked about it.

I also worked on some IInternetProtocol implementations so that Internet Explorer can work with alternate URL schemes.

So, I started an open source project some time ago: http://xxm.sourceforge.net/

This allows you to freely switch between the ISAPI extension, a stand-alone server, and possibly a later one. (The Apache module and Firefox protocol handler are in the process of being created.)

Delphi code and HTML are combined into the same source files as other web scripting languages, but use the (fast) Delphi compiler to create the libraries used to run the website.

Answer 6

I have written several applications that implement the Indy HTTP stack and provide web services. It can be easy and difficult. Complexity arises when you start working with streams, since you need to know how Indy creates streams for HTTP requests. Therefore, integration with the server code may require some thought, especially if the server connects to a data source or general controls for a certain type.

In addition, you need to manage all the security, access to files and almost everything else that a regular web server will do. Here, where you can peel off, because there are limited examples for Indy.

Having said that, I found that the Indy 10 HTTP server is reliable and works very well if you focus on specific requirements, for example, just serve XML based on what your application does. You have full control over what the server does, and you can choose between different deployment models - Windows Service, Stand-Alone App, etc.

If you have a well-designed thread-safe application, then implementing HTTP on top of it can be as simple as removing the Indy HTTP Server component on a form or unit. No need to duplicate any code for web content only.

Answer 7

I always focus on ISAPI and use IDDebugger to debug this process. This gives you the best of both worlds, debugging the same version that you ultimately deploy. Unfortunately, I do not develop Apache, so I can not talk about its ease of development.

Since I use this method, I never have to worry that changes between standalone ISAPI versions and synchronized ISAPI versions can easily drop the client version into my test environment in order to duplicate any specific behavior, and then test this behavior with fix and be absolutely sure that it will work when deployed in the field.

There are too many things to think about, even consider using a standalone web server facing the Internet. It is much better to put this concern (and many years of experience) in the hands of IIS / Apache.