The SP V4 design reduces the complexity of, but does not elimiinate, the need for web server or application framework agents in order to support a target environment. This document outlines the initial requirements for these agents and a proposed design breakdown of the software components needed.
Targets
- Determine C++ language standard to target while supporting the necessary platforms.
The initial target set of agents are those already supported: Apache (2.4 only), IIS 7+, and FastCGI. Of these, Apache and FastCGI need to be in C/C++, while it is in principle possible that IIS could be implemented via .NET, and thus in other languages. Given that the majority of the code needed for IIS already exists (or is portable and necessary to support the others anyway), it’s probably we would include IIS in the initial C/C++ set.
I am not inclined to roll back the code we do have and write a lot of new code in C. Yes, it’s more portable, easier and faster to build, etc. It’s also far more error prone and lacking in basic library facilities that modern C++ has available. That said, the nature of that C++ code needs to change radically, simplifying and modernizing it, dropping the use of templates wherever possible, and sticking to the standard library only. The nominal target would be C++11, but we need to research whether a newer version would be practical.
Dependencies
The only allowable dependencies must be usable on both Windows and non-Windows platforms (or there must be native alternatives to use). The set should be as minimal as possible. At this stage, only the following has been identified as critical needs:
Regular expressions
TLS-capable HTTP 1.1 client that allows basic control of server trust anchors (NOT the advanced metadata-driven trust evaluation support we use today).
C++11 has standard liibrary support for regular expressions.
The most obvious choices to use for HTTP are the native Windows client (for Windows obviously) and libcurl + OpenSSL (for everythiing else). In principle, libcurl with a different TLS implementation would work given that we stick to the higher level TLS options exposed by libcurl. Notably, this will pull libcurl and a TLS library into the in-process agent footprint, something we avoided in the current SP to avoid symbol conflicts between Apache and the agent. As long as the same version of OpenSSL is used between libcurl and Apache’s mod_ssl, that shouldn’t cause problems, and most Linux distributions would typically do that.
Major Components and Interfaces
This is a breakdown of the major pieces of the implementation. These proceed in a very inexact “lowest” to “highest” order, with later pieces typically depending on some of the earlier ones.
Library/Agent initialization/shutdown
Non-XML-based configuration support
Logging abstraction
syslog
Apache error log
Windows event log
Dynamic library mechanism for plugins/extensions
DDF (remoted data representation and serialization)
HTTP transport between agent and Java hub
Curl-based implementation
Windoes-based implementation
HTTP abstraction for web server integration
Session cache
Session abstraction
File-backed implementation
Chunked cookie implementation
Handler framework
Session initiator handler
Token consumer handler
Logout handlers
Other handlers
Web server bridges to interface to requests and responses
Portable authorization via RequestMap
Native modules
Apache 2.4 module
IIS module
FastCGI authorizer and requester