The Apache HTTP Server Project is an effort to develop and maintain an open-source HTTP server for modern operating systems including UNIX and Windows NT. The goal of this project is to provide a secure, efficient and extensible server that provides HTTP services in sync with the current HTTP standards.
Apache has been the most popular web server on the Internet since April 1996. The November 2005 Netcraft Web Server Survey found that more than 70% of the web sites on the Internet are using Apache, thus making it more widely used than all other web servers combined.
IBM HTTP Server
Overview
The foundation of any e-business application is the Web server. New IBM e-business software, such as the WebSphere family of products, is designed to operate with many popular Web servers. You do not need to change Web servers to take advantage of the latest IBM Web application technology.
IBM HTTP Server features include: Easy installation
Support for SSL secure connections
Fast Response Cache Accelerator
IBM support as part of the WebSphere bundle
Hardware crypto support
Administration Server that helps to administer and configure IHS servers.
Help information that uses the easy-to-navigate design that is common to all WebSphere products
IBM HTTP Server runs on AIX, HP-UX, Linux, Solaris, Windows 2000 and Windows NT
Features of the HTTP Server
Both HTTP Server (original) and HTTP Server (powered by Apache) have their own advantages, but which product should you choose? This tip provides a functional comparison about these products to help answer this question.
In addition, IBM plans for V5R2 to be the final release to support HTTP Server (original). IBM HTTP Server (powered by Apache) is the recommended solution for your Web serving needs. IBM plans for the HTTP Server (original) to be removed from IBM HTTP Server for iSeries in a future release.
This tip provides a good overview of the features and functions of the iSeries HTTP Server (powered by Apache) independent of the HTTP Server (original). This comparison is done at the OS/400 V5R2 versions of both the HTTP Server (powered by Apache) and HTTP Server (original). The Rochester lab created program temporary fixes (PTFs) for V5R1 for much of the HTTP Server (powered by Apache) functionality. In essence, this comparison is true for V5R1 with the exception of these features for which PTFs were not created:
Fast Response Cache Accelerator (FRCA)
Collection Services performance data
Support for independent auxiliary storage pools (IASPs)
.
Contents
_
The following information was extracted from HTTP Server (powered by Apache): An Integrated Solution for IBM ~ iSeries Servers, SG24-6716, which is currently a draft redbook (Redpiece). This redbook has more details and provides step-by-step instructions.
HTTP Version 1.1 Both original and Apache Both products support HTTP Version 1.1 (written as HTTP/1.1). The HTTP protocol implementation in Apache was chiefly architected by one of the HTTP/1.1 authors. Most current versions of popular Web browsers support HTTP/1.1. Apache is normally configured to detect popular browsers that do not properly support HTTP/1.1, and use only HTTP/1.0.
Persistent connections Both original and Apache When you enter a Uniform Resource Locator (URL) into your browser’s address line or click a link on a Web page, you open a connection between your browser and the HTTP server. Prior to the availability of persistent connections, each file referenced on the Web page was retrieved using a separate connection. This type of retrieval is tremendously costly for the HTTP server and the network since overhead is required to establish and terminate each connection. Persistent connections are the default behavior for an HTTP server that implements the HTTP/1.1 protocol.
GUI configuration and administration Both original and Apache You can configure and administrate HTTP server instances from Web browsers. To reach the iSeries Tasks page, enter the following command to start the Admin server:
STRTCPSVR SERVER(*HTTP) HTTPSVR(*ADMIN)
Then type the following URL from a Web browser:
http://
:2001
This brings you to the iSeries Tasks page. From there, click IBM HTTP Server for iSeries. This allows you to configure either the original or HTTP Server (powered by Apache).
Tip: The admin server’s port 2010 can be configured for a Secure Sockets Layer (SSL) or Transport Layer Security (TLS) encrypted session.
The HTTP Server (original) and the HTTP Server (powered by Apache) can coexist. That is, you may have zero, one, or many original servers running at the same time you have zero, one, or many HTTP Server (powered by Apache) servers running. The administration screen allows you to create and manage HTTP servers.
Both the HTTP Server (powered by Apache) and HTTP Server (original) have fully translated the GUI into the world’s languages.
Virtual hosts Both original and Apache You can enable virtual hosting. This allows you to host any number of Web sites through one communications adapter. With virtual hosting, you do not need to assign a unique port to each Web site. Virtual hosting is useful if you need to provide multiple “top-level” URLs for your Web sites or if you provide Internet Service Provider (ISP) services to clients.
Dynamic virtual hosting Only in Apache The dynamic virtual host allows you to dynamically add Web sites (host names) by adding directories of content. This approach is based on automatically inserting the IP address and the contents of the Host: header into the path name of the file that is used to satisfy the request.
Basic authentication Both original and Apache Basic authentication is a popular way to secure Web resources. You can protect Web resources by asking the user for a user ID and password to gain access to these resources. Specifically for the HTTP Server (powered by Apache), the user ID and password on the iSeries can be validated in one of three ways:
OS/400 user profile: This requires that each user must have a system user profile.
Validation list: This requires you to create a validation list that contains Internet users.
Lightweight Directory Access Protocol (LDAP) server: This requires that you configure a LDAP server with the user entries.
SSL and TLS Both original and Apache Secure Sockets Layer has become an industry standard for enabling applications for secure communication sessions over an unprotected network (such as the Internet). With the SSL protocol, you can establish secure connections between clients and server applications which provide authentication of one or both end points of the communication session. SSL also provides privacy and integrity of the data that client and server applications exchange.
Multiple versions of the SSL protocol are defined. The latest version, TLS Version 1.0, provides an evolutionary upgrade from SSL Version 3.0.
Both the HTTP Server (original) and the HTTP Server (powered by Apache) support server authentication and client authentication using digital certificates. With server authentication, the client ensures that the server certificate is valid and that it is signed by a Certificate Authority (CA), which the client trusts. With client authentication, the server ensures that the client certificate is valid and that it is signed by a CA, which the server trusts.
Proxy caching Both original and Apache The IBM HTTP Server for iSeries can be configured as a non-caching or caching proxy server. When used as a non-caching proxy, the primary benefit of enabling proxy services is that the Internet Protocol (IP) addresses used on the internal network are not sent from your network. The proxy service forwards the request from your internal network using the IP address of the proxy server, not the address of the original requester. When the proxy server receives the response, it forwards the response to the original requester.
With caching enabled, the proxy server can act as a high-speed local store of previously accessed Web pages. When you configure the server as a proxy caching server, you can improve performance. You can also allow users of your internal network to access documents on the Internet. For example, if you frequently access the same set of Web pages from one or more sites, it may be advantageous to activate the caching feature. The retrieved Web page is stored locally on your iSeries server. Any subsequent accesses to the page occur at local area network (LAN) speed, rather than at Internet speed.
Web pages can be encoded with a “no-cache” attribute or a specific expiration date. You can also configure the IBM HTTP Server for iSeries proxy service so that it periodically performs “garbage collection” to remove expired files from the cache.
Another use of the proxy service (with or without caching) is to log client requests. Some of the data available includes:
Client IP address
Date and time
URL requested
Byte count
Success code
With this information, you can construct reports to account for the use of your Web site. For example, the information can be used in a charge-back system to understand and track marketing trends.
Reverse proxy caching Only in Apache A reverse proxy is another common form of a proxy server. It is generally used to pass requests from the Internet, through a firewall to isolated, private networks. It is used to prevent Internet clients from having direct, unmonitored access to sensitive data residing on content servers on an isolated network or intranet. If caching is enabled, a reverse proxy can also reduce network traffic by serving cached information rather than passing all requests to actual content servers. Reverse proxy servers may also balance workload by spreading requests across a number of content servers. An advantage of using a reverse proxy is that Internet clients do not know their requests are being sent to and handled by a reverse proxy server. This allows a reverse proxy to redirect or reject requests without making Internet clients aware of the actual content server (or servers) on a protected network.
In addition, the HTTP Server (powered by Apache) can use FRCA, which incorporates both a local cache and another reverse proxy cache. That is, both the HTTP Server (powered by Apache) and FRCA can be configured as a reverse proxy cache.
Local memory cache Both original and Apache A proxy cache is traditionally most beneficial to clients on your network since it lets you store files that were retrieved from other Web sites. You can provide a caching service for files on your site using the local memory cache configuration options.
To use a local memory cache, you identify an amount of memory to allocate and a set of files to be cached. When the IBM HTTP Server for iSeries is started, the files are read into the local memory cache up to the limit of the amount of memory allocated or the limit of the number of files that you allow to be cached.
When a request is received at your IBM HTTP Server for iSeries, the local memory cache is checked first to determine if it has a copy of the requested file. If so, the file is served from the cache, which can be significantly faster than if the file is retrieved from disk storage.
In addition, the HTTP Server (powered by Apache) (only) supports FRCA, which also has a local cache option.
Server-side includes Both original and Apache Server-side includes (SSI) enable the server to process some of the Web pages before the server sends the page to the client. The current date, size of the file, and the last change date of a file are examples of the kind of information that you can include in Web pages that you send to the client.
Tip: There is little difference between the HTTP Server (original) and HTTP Server (powered by Apache) implementation of SSI. The reason? The Apache Software Foundation initially designed the syntax for SSI that IBM later used in its HTTP Server (original).
Common Gateway Interface (CGI) programming Both original and Apache Corporations and other customers benefit from interacting with browser users by sending and receiving data. In the Web presence arena, this type of transaction is simple, such as collecting the name and address of a browser user who wants to receive a catalog. In general, these interactions start with a form – a Web page that contains input-capable fields and push buttons (like function keys). The server needs to hand the input from the form to a program for processing.
Typically, on the iSeries server (and most other platforms), this program is a CGI program. The CGI program receives the form data from the browser, accesses business data and business logic on the iSeries server, updates or stores information (if required by the transaction), and then builds the Web page that the HTTP server returns to the browser user in response.
CGI programs written for the HTTP Server (original) function the same way for the HTTP Server (powered by Apache).
In addition, CGI applications working with the HTTP Server (powered by Apache) can:
Control the number of CGI jobs started with the server and their user profile
Run OS/400 PASE (UNIX binaries) applications as CGI programs
LDAP support Both original and Apache HTTP servers can use LDAP to store:
Configuration information: See Implementation and Practical Use of LDAP on the IBM ~ iSeries Server, SG24-6193, for information about how to use LDAP to store (and share) HTTP server configurations throughout your network.
User authentication information
Webserver Search Engine and Web Crawler Both original and Apache The HTTP Server search engine allows you to perform full text searches on Hypertext Markup Language (HTML) and text files stored in the iSeries file system from any Web browser. The iSeries Webserver Search Engine is available at no charge with IBM HTTP Server for iSeries (5769-DG1 or 5722-DG1) starting at OS/400 V4R4. You can control what options are available to the user and how the search results are displayed through customizable Net.Data macros.
On the iSeries, the search engine comes in two logical pieces that are related to each other.
Web-based Distributed Authoring and Versioning (WebDAV) Both original and Apache WebDAV provides a network protocol for creating interoperable, collaborative applications. Major features of the protocol include:
Locking (concurrency control): Long-duration exclusive and shared write locks prevent the problem of overwriting, where two or more collaborators write to the same resource without first merging changes. To achieve robust Internet-scale collaboration, where network connections may be disconnected arbitrarily, and for scalability, since each open connection consumes server resources, the duration of DAV locks is independent of any individual network connection.
Properties: Extensible Markup Language (XML) properties provide storage for arbitrary metadata, such as a list of authors on Web resources. These properties can be efficiently set, deleted, and retrieved using the DAV protocol. The DAV Searching and Locating (DASL) protocol provides searches based on property values to locate Web resources.
Namespace manipulation: Since resources may need to be copied or moved as a Web site evolves, DAV supports copy and move operations. Collections, similar to file system directories, may be created and listed.
For more information about WebDAV, refer to:
http://www.webdav.org/
Access log reporting and Web usage mining Only in original The HTTP Server (original) provides the log reporting and Web usage mining function. If you are using HTTP Server (powered by Apache), you can obtain the IBM WebSphere Site Analyzer to provide a similar function.
Tip: The market is full of Web log analyzer software that support the industry-standard common and combined log formats for Apache. The HTTP Server (powered by Apache) uses these same formats. Choose the one you feel is the best value for the money.
Both servers include complete facilities to log client access, server errors, and other forms of customizable information.
Log rollover and maintenance Both original and Apache The HTTP Server (original) supports daily log files only. When a server instance is started, all of the log files configured for that server instance are opened. By default, the server does not create any logs. The proper directives must be configured by the web administrator to cause the HTTP server to log. Web server instances may not share log files.
The Apache code as shipped from ASF has no automatic rollover capability. If the user wants the current log rolled, the support must be implemented via a user program.
In V5R2, the iSeries has extended this feature with the HTTP Server (powered by Apache) to include log rollover support. This is in the form of the HTTP Server (original) support. It is then extended by allowing the user to specify a value of Off, Hourly, Daily, Weekly, or Monthly. The directive that provides log rollover support is LogCycle.
Platform for Internet Content Selection (PICS) Only in original PICS support enables labels (metadata) to be associated with Internet content. Originally designed to help parents and teachers control what children access on the Internet, it also facilitates other uses for labels, including code signing and privacy.
Tip: PICS never found wide-spread support in the industry. This is why you do not find this support on the HTTP Server (powered by Apache) and other Apache servers.
Domino plug-in Both original and Apache The Domino R5 plug-in allows the HTTP Server (original) to access Domino documents. See Domino and WebSphere Integration on the IBM ~ iSeries Server, SG24-6223, for details in regard to the HTTP Server (original) only.
For Domino 6, a plug-in allows the HTTP Server (powered by Apache) to access Domino documents. This plug-in supports the HTTP Server (powered by Apache) at V5R2 of OS/400 and a PTF was created for V5R1. See IBM Lotus Domino 6 for iSeries Implementation, SG24-6592, for details about the HTTP Server (powered by Apache).
Domino 6 does not support the HTTP Server (original).
For the latest information, see:
http://www.ibm.com/servers/eserver/iseries/domino/
WebSphere Application Server plug-in Both original and Apache The IBM HTTP Server for iSeries handles static content, CGI program invocations, and proprietary plug-ins. The WebSphere Application Server run-time environment plugs into IBM HTTP Server for iSeries using plug-in application programming interfaces (APIs). This extends the support of the HTTP Server to include an implementation of the Java 2 Platform, Enterprise Edition (J2EE) specification from SUN Microsystems.
Apache Software Foundation’s Jakarta Tomcat Only in Apache The HTTP Server (powered by Apache) includes an industry-standard Java servlet and JavaServer Pages (JSP) container based on technology from the Apache Software Foundation's Jakarta Tomcat open source code base. Lightweight and easy-to-use software extends the HTTP Server (powered by Apache) server and is compliant with the Java Servlet 2.2 and JavaServer Pages 1.1 specifications from SUN Microsystems.
Apache Software Foundation's Jakarta Tomcat for iSeries support can be used as a simple starting point for business partners and customers interested in learning about or piloting Java servlet and JSP applications. This support is based on Version 3.2.4 of the Jakarta Tomcat specification.
For more information, refer to the iSeries HTTP server Web page at:
http://www.ibm.com/eserver/iseries/software/http
HTTP Server (original) API Only in original HTTP Server (original) APIs are not supported on HTTP Server (powered by Apache). The strategic direction of IBM is to extend the function of the Web server using Java servlets rather than with modules or server APIs. This function can only be used in HTTP Server (original).
Apache Portable Runtime (APR) and modules Only in Apache The design of the Apache HTTP server is one that defines modules. Modules are operating system objects that can be dynamically linked and loaded to extend the base nature of the Apache HTTP server. Depending on the operating system, this is similar to:
Window's Dynamic Link Libraries (DLL)
UNIX's shared object libraries
OS/400's integrated language environment (ILE) Service Programs
In this way, the Apache modules provide a way to extend a server's function. Functions commonly added by optional modules include:
Authentication
Encryption
Application support
Logging
Support for different content types
Diagnostics
Compression
You can extend the core functionality of the HTTP Server (powered by Apache) by writing your own modules or porting other modules to the iSeries.
Support for the TRCTCPAPP command Only in Apache The Trace TCP/IP Application (TRCTCPAPP) command can be used to trace the server, but only one instance at a time. It can be started while the server is running.
Note: The old -vv (very verbose) still works at startup much like the original server (and -vi and -ve, which stand for informational and error tracing, respectively). You can use the Dump User Trace (DMPUSRTRC) and Display Physical File Member (DSPPFM) commands to see the results. However, we recommend that you use the TRCTCPAPP method.
Collection Services performance data Only in Apache The HTTP Server (powered by Apache) supports collection services and provides performance data specific to the HTTP server. It uses a new feature in V5R2 from Collection Services for user-defined categories and probes. This support allows IBM products and customer applications to capture application unique performance data along with the system data already provided by collection services.
Note: The HTTP Server (powered by Apache) does not support the mod_status module’s /status function. Instead, IBM chose to write performance-related information to collection services.
Triggered Cache Manager (TCM) Both original and Apache Triggered Cache Manager provides a mechanism to manage dynamically-generated Web pages. TCM is a separate server that can be used in conjunction with the HTTP server to allow a Web designer to build dynamic pages. It only updates the cache when the underlying data changes, thereby improving the performance of a Web site.
Fast Response Cache Accelerator (FRCA) Only in Apache Working with the HTTP Server (powered by Apache) FRCA provides a cache mechanism that dramatically improves the file serving performance on your iSeries. FRCA operates below the Machine Interface (MI). It eliminates much of the overhead involved in switching to above MI threads. This enables FRCA to accelerate the delivery of an individual file found in its cache. It also reduces the amount of CPU needed to handle the request (as compared to HTTP Server (powered by Apache). FRCA can handle both a static file caching and a dynamic reverse proxy caching.
mod_deflate Only in Apache mod_deflate is a powerful tool that allows you to compress, by configuration, files being served from your HTTP Server (powered by Apache). mod_deflate is Apache's open source equivalent to mod_gzip. Compressing the data being sent by your HTTP Server (powered by Apache) can dramatically save on network delays due to bandwidth restrictions. The data is decompressed at the remote client’s Web browser. mod_deflate is particularly useful in networks where individual links are saturated with traffic or the end-user is connected via MODEM. Of course, the compression of the data takes additional resources on both the server and client so use care with this powerful module.
As an anecdotal example, consider the /index.html home page that is served from the NetObjects Fusion generated sample Web application used in the redbook "HTTP Server (powered by Apache): An Integrated Solution for IBM eServer iSeries Servers", SG24-6716. It is compressed by mod_deflate from 10867 to 2002 bytes.
Highly available HTTP server Both original and Apache If Web serving is a critical aspect of your business, you may want high availability for your Web server environment. A highly available Web server takes advantage of iSeries clustering technology and makes it possible to build a highly available Web site. This improves the availability of business-critical Web applications built with CGI programs.
Support for IASPs Only in Apache An IASP is a collection of disk units that you can bring online or take offline independent of the rest of the storage on a system. Each IASP contains all of the necessary system information associated with the data it contains. While the system is active, you can take the IASP offline, bring it online, or switch between systems. IASPs can contain either:
One or more user-defined file systems
One or more external libraries
This feature was fully tested with the V5R2 delivery of the HTTP Server (powered by Apache). It is not supported on the HTTP Server (original).
Asynchronous input/output (I/O) Only in Apache The HTTP Server (powered by Apache) processes communications requests asynchronously. In this asynchronous I/O model, threads are only involved in processing when there is work to be done. Threads are dispatched to perform work as required. When not performing work, the threads are returned to a pool of available threads making the server process more efficient and improving performance by better utilizing the thread resources. Asynchronous I/O also makes the server more scalable to support a high number of users especially when combined with persistent connections.
Denial of service Both original and Apache The denial of service configuration directives are equally performance settings and a security. These directives allow you to identify, based on the data frame size, the possibility of an attack. The HTTP server may identify an attack because the frame size differs to the one it expects. Although this setting impacts the server performance as each request is tracked, it allows you to prevent a more dangerous performance degradation when dealing with a type of attack that may intentionally slow down or even completely paralyze your server.
Although both servers have denial of service safeguards, the two solutions are different and provide different kinds of denial of service protections.
http://www-306.ibm.com/software/webservers/httpservers/