Product Notes and Known Issues
This chapter covers:
General Licensing Notes
InterSystems makes its products and features available under license to customers. While InterSystems may or may not enforce the use of said products or features consistent with the purchased license capabilities, customers are expected to comply with terms of their licenses. Moreover, InterSystems may tighten enforcement at any release without notice.
Developers must be aware that certain license types are required in order to use specific product features such as Multi-Server capability, Mirroring, and Web Services features. The specific requirements are noted in the InterSystems Price List and the Terms and Conditions for licensing. These are available from your local InterSystems representative.
Application Use of InterSystems Web Server
InterSystems installs an Apache-based web server (often referred to as the "private web server") to assure that the Management Portals for its products are always available. The private web server is built and configured to meet the management needs of InterSystems administrative servers and is configured to only connect to InterSystems products. The options selected are not, in general, suitable for production use - in particular, security is minimal and the options used are generally unsuitable for a high volume of HTTP requests. Testing, by InterSystems, of the private webserver only covers use of the private web server for managing Caché, Ensemble, HealthShare, and other InterSystems products.
Customers are not required to use this web server to manage our products. You may also use a web server of your choice, located on whatever server you elect to use. The private web server is provided as a convenience to simplify installation and installation dependencies. Many developers also find it useful to use the private web server for unit testing.
The parameters used for the UNIX® build are:
--prefix=<installation_location> --disable-actions --disable-asis --disable-auth --disable-autoindex --disable-cgi --disable-cgid --disable-charset-lite --disable-dir --disable-env --disable-imap --disable-include --disable-negotiation --disable-setenvif --disable-shared --disable-status --disable-userdir --enable-access --enable-alias --enable-log-config --enable-mime --enable-so --without-berkeley-db --without-gdbm --without-ndbm
The server produced has defaults using the Apache Group’s prefork Multi-Processing Module (MPM). This is the non-threaded server model. The number of requests that can be concurrently served is directly related to the number of Apache worker processes in the pool. The private web server is configured to occupy the smallest possible footprint by allowing a maximum of two worker processes to be created for the pool. The following settings will be found in the Apache configuration (httpd.conf) for the server:
By contrast, the default Apache configuration for a production grade build is usually the following:
This configuration will allow Apache to create 5 worker processes at start-up time, increasing to a maximum of 256 as the concurrent load increases. Because of these differences in configuration, the performance of the private web server will be noticeably inferior to that of a production grade Apache build as the concurrent load increases.
Windows-based Apache installations use the official binary distribution for Windows and a special multithreaded Multi-Processing Module (MPM) which is more suited to the way the operating system is optimized. However, since InterSystems installs and loads only a small subset of modules (mod_alias.so, mod_authz_host.so, mod_log_config.so and mod_mime.so.), their functionality is limited.
If you expect very low volume of HTTP traffic, have limited demands for high availability and secure operation, the private web server may be suitable for your deployment needs. However, if you expect a high amount of HTTP traffic, require high availability in your web server, need to integrate with other sources of web information, or need a high degree of control over your web server, InterSystems recommends installing your own separate copy of Apache, ideally on its own server, and configuring it to use our CSP gateway to communicate with Cache, Ensemble, or HealthShare. Review the options above to determine if this is so.
Issue: Website and CSP Application Login Problems Due to the SameSite Attribute
Recent updates to browser security have changed handling of third-party cookies. These updates use the SameSite attribute to reduce the risk of cross-site request forgery (CSRF) attacks, unauthorized access to data, and other possible security issues. Chrome (starting with v.84) enforces stricter rules for SameSite behavior, and these rules can cause issues with existing websites and CSP applications. These issues may include login problems, the login page being displayed repeatedly, and page elements not displaying properly. Because this version of Caché does not support modifications to the SameSite attribute, CSP applications running on this version may have such issues. InterSystems has added functionality to its CSP applications that will allow you specify default values for the SameSite attribute, which will thereby prevent third-party cookie issues from arising; this functionality will be available in version 2018.1.5 of Caché. If you encounter this issue, please contact the InterSystems Worldwide Response Center (WRC) for additional help.