Lost compatibility with many third-party modules

[RekGRpth]

1. Commit 6523dbe removed the captures_mask field from the ngx_http_script_compile_t structure in src/http/ngx_http_script.h. It was used in third-party plugins, such as ngx_http_substitutions_filter_module, and they are now incompatible with freenginx.

2. Commit c6a18ac removed the definition of the ngx_http_script_var_handler_code_t structure from src/http/ngx_http_script.h. It was used in third-party plugins, such as ngx_devel_kit, which many other third-party modules depend on, and they are now incompatible with freenginx.

Is it a good thing that freenginx has now lost compatibility with many third-party modules?

[mdounin]

The captures_mask field is an internal field, needed solely for the optimization which was removed by the commit in question. Use of this field by the ngx_http_substitutions_filter_module suggests the issue in the module, and the code seems to confirm that the author is aware of this. Nevertheless, it should be trivial to fix the module to be compatible - the most trivial fix would be to always assume there are captures, and checking sc->ncaptures instead of captures_mask would probably be the minimal change compatible with both old and new code, including freenginx and F5 NGINX.

Similarly, the ngx_http_script_var_handler_code_t structure is a more or less an internal structure used solely by the rewrite module. Trying to use it elsewhere might be unwise, and given that the module also copy-pastes various rewrite functions and even reinterprets config of the ngx_http_rewrite_module configuration using a private copy of the non-public ngx_http_rewrite_loc_conf_t structure, I think that the risks are well-understood by the author. Nevertheless, a trivial fix would be to remove usage of the ngx_http_script_var_handler_code_t structure along with v->set_handler checks altogether for freenginx 1.31.3 and above, similarly to what the commit in question does.

In general, it should be understood that changes in freenginx are expected to happen, and this will break compatibility with various 3rd party modules. Especially if these modules use internal fields and structures which aren't part of the API provided, but not limited to: changes to public API are also expected to happen from time to time. Correct approach would be to fix the modules to be compatible with the new freenginx code.

The mechanism to do proper compile-time checks was introduced in #12, and several patches made by @osokin were already accepted into various 3rd party modules.

Does this answer the question?