Opened 13 months ago
Closed 13 months ago
#2556 closed defect (invalid)
Module ABI breakage with NGINX Plus R30 P1
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | nginx-module | Version: | 1.25.x |
Keywords: | Cc: | ||
uname -a: | |||
nginx -V: |
nginx version: nginx/1.25.1 (nginx-plus-r30-p1)
built by gcc 8.5.0 20210514 (Red Hat 8.5.0-18) (GCC) built with OpenSSL 1.1.1k FIPS 25 Mar 2021 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-http_v3_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --build=nginx-plus-r30-p1 --with-http_auth_jwt_module --with-http_f4f_module --with-http_hls_module --with-http_proxy_protocol_vendor_module --with-http_session_log_module --with-stream_mqtt_filter_module --with-stream_mqtt_preread_module --with-stream_proxy_protocol_vendor_module --with-cc-opt='-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -pie' |
Description
The said binaries are claiming that they are based on 1.25.1, however, with the h2 patch applied, ngx_http_v2_connection_s structure would've had changed to include two new members, which renders modules compiled against the actual 1.25.1 sources incompatible with the shipped binaries if there are such references to the h2 connection structure.
Change History (3)
comment:1 by , 13 months ago
comment:2 by , 13 months ago
Unfortunately, the use case is that it is sometimes useful to retain the behavior of setting r->keepalive = 0 in the context of multiplexed connections by sending GOAWAY frames. Vanilla code cannot do this and a 3rd-party module which would do this will then need to access the h2c->goaway member which happens to be the last member in the structure.
It would be nice to have a clear layout of the current ngx_http_v2_connection_t in the shipped plus binary so that such modules can be compiled in a compatible way, and further to have a similar function like ngx_http_v3_shutdown() and having an external linkage.
comment:3 by , 13 months ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
As already outlined by Roman, the ngx_http_v2_connection_t structure is not really a public interface, and any issues which happen due to attempts to accesses it directly is solely responsibility of the module which does this. Even if ABI compatibility is preserved, there can be arbitrary behaviour changes, which will render such a module invalid.
Either way, please note that this is a ticket tracker for nginx, not NGINX Plus. If you have issues with NGINX Plus, please contact NGINX Plus support instead.
Indeed ngx_http_v2_connection_t layout has changed since https://hg.nginx.org/nginx/rev/cdda286c0f1b. This can only be a problem for 3rd-party modules which allocate instances of this structure or explicitly access the fields (past "idle") of the structure allocated by http2 implementation and referenced by
c->data
. Both are possible but unlikely. Regular http code is not affected by this.