vAdd Server API directives to your configuration file so that you can associate your program’s application functions with the appropriate step. There is a separate directive for each server request processing step. You must stop and restart the server for the new directives take effect.

vTest your program rigorously. Because IBM HTTP Server is a theaded server, you should apply more rigorous testing than you would for a forked server. Because the server calls your program directly and they both run in the same process space, errors in your program can stop the server.

Basic server request process

You can break down the basic server request process into a number of steps, based on the type of processing the server is performing during that phase. Each step includes a juncture at which a specified part of your program can run. The Server API directives in your configuration file, indicate which of your application functions you want called during a request process step.

Your compiled program exists as a service program. As the server proceeds through its request process steps, it calls the application functions associated with each step, until one of the functions indicates it has handled the request. If you have more than one of your application functions indicated for a particular step, your functions are called in the order in which they appear in the configuration file.

If the request is not handled by an application function (either you did not include a Server API directive or your application function for that step returned HTTP_NOACTION), the server performs the default action for that step.

Note: This is true for all steps except the Service step; the Service step does not have a default action.

The following list indicates the purpose of each step and defines the processing order.

Server Initialization

Performs initialization functions before any client requests are read.

PreExit

Performs processing after a request is read but before anything else is done.

If this step returns an indication that the request was processed

(HTTP_OK), only the Data Filter, Log and PostExit steps, in the request process are performed.

Authentication

Decodes, verifies, and stores security tokens.

Name Translation

Translates the virtual path (from URL) to the physical path.

Authorization

Uses stored security tokens to check the physical path (protections, acls) and generates the WWW-Authenticate headers required for basic authentication. If you write your own application function to replace this step, you must generate these headers yourself.

Object Type

Locates the file system object that is indicated by the path.

110Web Programming Guide V4R5

Page 119 Page 121
Page 120
Image 120
IBM AS/400E manual Basic server request process
Page 119 Page 121

AS/400E specifications

The IBM AS/400E, now more commonly known as IBM i, is a robust and versatile midrange server that has been designed to provide a comprehensive computing solution for businesses of all sizes. First introduced in the late 1980s, the AS/400 series has undergone multiple enhancements and rebranding, with the AS/400E being one of the notable iterations. This powerful platform is closely associated with IBM's commitment to reliability, scalability, and integrated business solutions.

One of the main features of the AS/400E is its highly integrated architecture that combines hardware and software into a cohesive system. This integration allows for seamless operations, reducing the complexity typically associated with managing disparate systems. The system is powered by IBM's proprietary OS/400 operating system, which has evolved into IBM i, featuring advanced capabilities like object-oriented programming, integrated database management, and security features that are essential for enterprise environments.

A key characteristic of the AS/400E is its robust database support, primarily through the use of DB2 for i. This integrated database management system enables efficient data handling and retrieval, facilitating real-time business analytics and reporting. Furthermore, the platform supports a variety of programming languages, including RPG, COBOL, and Java, making it flexible for developers who require diverse tools for application development.

The AS/400E is also known for its exceptional reliability and uptime, making it a preferred choice for critical business applications in industries such as finance, healthcare, and manufacturing. This reliability is backed by advanced error detection and correction mechanisms, as well as redundancy features that help prevent data loss and minimize downtime.

In terms of scalability, the AS/400E can effortlessly expand to accommodate growing business demands. Organizations can increase processing power by adding more resources without significant disruption. This scalability, combined with the system’s built-in virtualization capabilities, allows businesses to optimize resource usage and streamline operations.

Security is another defining feature of the AS/400E. The platform incorporates various layers of security measures, including user authentication, encryption, and comprehensive auditing capabilities, ensuring that sensitive business data is protected against unauthorized access.

Overall, the IBM AS/400E remains a powerful tool in the enterprise computing landscape, providing businesses with an integrated, reliable, and secure solution for their technological needs. Its enduring popularity is a testament to its capability to evolve with changing business requirements while maintaining its core attributes of high performance and stability.
Top Page Image Contents