Page Comparison

...

Targets

...

•  Determine C++ language standard to target while supporting the necessary platforms.

...

and Language

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 obvious target would be C++11, but we need to research whether a newer version would be practical. Elimination of various Boost-based tricks is essential, especially non-standard lambda and parameter binding templates.

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 library 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 problemsC++14 is supported on all of the “current” platforms we support (granted, a very small set) and appears to be supported on all non-EOL versions of Debian/Ubuntu. The main outliers for C++14 support are RHEL 7 (and similar) and Suse 12, neither of which are actively supported, though we do build packages for CentOS 7 and Amazon Linux 2. The former addresses RHEL 7, which is extremely widely adopted (and will be long past its EOL date).

That’s not accounting for the fact that it will be likely 2 years until this code is ready for wide adoption, which makes C++14 a practical option if it offers any benefit over C++11, but probably not otherwise.

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 library 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.

...

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.

• Threading abstraction

• Non-XML-based configuration support

• Logging abstraction

  • syslog

  • Windows event log

  • Apache error log

• DDF (remoted data representation and serialization)

• HTTP transport between agent and Java hub

  • Curl-based implementation

  • Windows-based implementation

• HTTP Request/Responose abstraction

• Session cache

  • Session abstraction

  • File-backed implementation

  • Chunked cookie implementation

• Handler framework

  • Session initiator handler

  • Token consumer handler

  • Logout handlers

  • Other handlers

• Portable authorization via RequestMap

• Web server bridges to interface to requests and responses

• Native modules

  • Apache 2.4 module

  • IIS module

  • FastCGI authorizer and requesterrequester

Unit Testing

The current (very lightly used) unit testing library is not great, and requires a Python-based processor. Boost has a unit testing framework inside it that can be used in both header-only and static/shared linking modes, and I’ve already done a bit with it enough to think it’s a good fit, particularly given the likely use of at least one other Boost library.

The plan is certainly to be much more extensive with tests so that much of the code can be run in isolation before connecting it to the Java and Web Server plug points on either side.

Threading Abstraction

The current code base provides a number of portability classes for abstracting POSIX and WIndoes threading APIs for threads, locking, condition variables etc. The main use of this code is around configuration reloads, and that’s valuable enough that it may still be worth doing. There are also some thread-local storage cases that may in some cases be hard to remove.

C++11 includes fairly complete APIs for all this, with the exception of shared locking, which was added in C++14. That probably means leaving the code as is unless we move to C++14 as a baseline. OTOH, that’s a missed opportunity to get rid of some sensitive code.

Configuration Support

The current configuration is predominantly XML-based, supplemented/bridged to native Apache commands on that platform (none of the other current agents support a usable configuration mechanism).

The RequestMap will continue to be supported as XML, while other needs may be possible to address with a simpler format (JSON is not simpler and is much less flexble, but an INI or property file is definitely simpler). Boost has a somewhat odd-looking Property Tree module that appears to be header-only (so easy to use without adding runtime dependencies), and it actually supports reading and writing to INI, JSON, and XML(!) with some limitations in each case.

That may be a viable way to parse the RequestMap without delegating to Java, and in fact the representation is rather similar to what I built in Java using my DDF library. (The whole abstraction is somewhat similar to DDF in fact.)

For now, it suffices to say that we need to identify what the settings needed are and their general structure before settling on an approach, but this Boost option looks like a good fit simply due to flexibilityand writing to INI, JSON, and XML(!) with some limitations in each case.

That may be a viable way to parse the RequestMap without delegating to Java, and in fact the representation is rather similar to what I built in Java using my DDF library. (The whole abstraction is somewhat similar to DDF in fact.)

For now, it suffices to say that we need to identify what the settings needed are and their general structure before settling on an approach, but this Boost option looks like a good fit simply due to flexibility.

With respect to IIS, it does turn out the newer version supports a native XML configuration layer that’s extensible. It appears to be very complex to use, and my guess is we’ll be better off looking at that as a possible future direction to explore but probably not a great drop-in replacement for what we have now.

Logging

Currently we use a fork of an old C++ logging library. The elimination of dependencies and the fact that having out of band logging streams from within a web server has never worked well demands we drop this in favor of “native” options. Logging is of course non-portable, and some web servers do their own logging.

...