summaryrefslogtreecommitdiffhomepage
AgeCommit message (Collapse)AuthorFilesLines
2025-05-01auto/modules/wasm: Remove an unneeded compiler optionAndrew Clayton1-2/+2
-Wno-missing-field-initializers was needed for GCC 4.8 / RHEL 7 etc to avoid warnings with {} empty initialisers. We haven't needed to support that compiler for sometime. Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-04-30Add SUPPORT.mdAndrew Clayton2-0/+12
Just replicating the "Maintenance and support guidelines" text from <https://unit.nginx.org/community/>. With a link to it from the README. Cc: Maryna Herasimovich <m.herasimovich@f5.com Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-04-28Treat a “broken pipe” on SSL_shutdown() as a normal closeAndy Postnikov1-1/+2
Starting with OpenSSL 3.4 errno is flowed up from tls_retry_write_records() which upon EPIPE results in the following log message 2025/04/23 17:12:47 [alert] 14322#14324 *16 SSL_shutdown(25) failed (32: Broken pipe) (32: [null]) (OpenSSL: error:80000020:system library::Broken pipe:tls_retry_write_records failure) Which is harmless except it trips up the test/test_tls.py::test_tls_certificate_change test due it to looking for "alert" log messages and failing if any are found. Now, I think the tests are wrong to do this (they also don't seem to be closing the TLS connection properly). But getting EPIPE when we're shutting down the connection is likely harmless so treat it the same as a clean shutdown which also gets rid of this log message. Link: <https://github.com/openssl/openssl/commit/933f57dfe21657f7aba8f13e0cdb3b02dd64fcc3.patch> Closes: https://github.com/nginx/unit/issues/1600 [ Commit message - Andrew ] Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-04-22tests: Fixed alt_names in test_tls_sni_same_altKirill A. Korinsky1-2/+2
alt_names should be an array of strings, When it is just a string we end up with an alt_names entry in openssl.cnf which contains: [ alt_names ] DNS.1 = s DNS.2 = a DNS.3 = m DNS.4 = e DNS.5 = . DNS.6 = a DNS.7 = l DNS.8 = t DNS.9 = n DNS.10 = a DNS.11 = m DNS.12 = e DNS.13 = . DNS.14 = c DNS.15 = o DNS.16 = m This may or may not work depending on TLS library due to the '.''s. I.e. OpenSSL accepts them LibreSSL doesn't and errors with 62345808257024:error:22FFF077:X509 V3 routines:CRYPTO_internal:bad object:x509/x509_alt.c:707:name=DNS value='.' What was much more likely intended was to end up with [ alt_names ] DNS.1 = same.altname.com [ Tweaked commit message - Andrew ] Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-04-21http: Compress application responsesAndrew Clayton3-1/+102
This adds initial support for compressing application responses. A couple of things to note 1) Compressed responses are sent 'chunked' as we don't know beforehand how large the compressed response will be. 2) We only compress responses where we know the Content-Length as we need to check with the 'min_length' config parameter. It's also currently how we track when we need to close the compression stream off. Co-authored-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-04-14http: Compress static responsesAndrew Clayton3-0/+133
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-04-14http: compress: Add a couple of helper functionsAndrew Clayton1-0/+29
This adds two helper functions that will be used in subsequent commits. nxt_http_comp_compress() does the actual compression. nxt_http_comp_bound() returns the maximum compressed size for the given size. Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-04-14http: Wire up HTTP compression support to the config systemAndrew Clayton2-0/+103
This exposes a new "settings.http.compression" configuration object. Under which are types & compressors objects. types is used to specify what MIME types should be considered compressible. compressors is used to configure an array of compressors that are available. For each of these, you specify the encoding, e.g gzip and optional level and min_length parameters. Where level is what compression level to use and min_length is the minimum length of data that should be compressed. By default the default compression level for the specified compressor is used and there is no minimum data length considered for compression. It may look something like "settings": { "http": { "server_version": true, "static": { "mime_types": { "text/x-c": [ ".c", ".h" ] } }, "compression": { "types": [ "text/*" ], "compressors": [ { "encoding": "gzip", "level": 3, "min_length": 2048 }, { "encoding": "deflate", "min_length": 1024 }, { "encoding": "zstd", "min_length": 2048 }, { "encoding": "br", "min_length": 256 } ] } } }, Currently this is a global option that will effect both static and application responses. In future it should be possible to add per-application (and perhaps even per-static) configuration. Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-04-14http: Wire up HTTP compression to the build systemAndrew Clayton6-2/+132
This allows to actually build unit with support for zlib, zstd and brotli compression. Any or all can be specified. E.g. $ ./configure --zlib ... $ ./configure --zlib --zstd --brotli ... During configure you will see if support for the requested compressions has been found and what version of the library is being used. E.g. ... checking for zlib ... found + zlib version: 1.3.1.zlib-ng checking for zstd ... found + zstd version: 1.5.6 checking for brotli ... found + brotli version: 1.1.0 ... Unit configuration summary: ... zlib support: .............. YES zstd support: .............. YES brotli support: ............ YES ... Co-authored-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-04-14http: Add support for brotli compressionAndrew Clayton3-0/+106
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-04-14http: Add support for zstd compressionAndrew Clayton3-0/+97
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-04-14http: Add zlib compression supportAndrew Clayton3-0/+128
This adds support for both deflate & gzip compressors. Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-04-14http: Add core http compression codeAndrew Clayton2-0/+543
This is the initial step to enabling HTTP compression on both static and application responses. This code itself doesn't do any actual compression, that will come in subsequent commits. It just contains the core functions for initialising structures that describe the available compressors and functions for checking if compression should be done depending on various criteria. Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-04-14http: Add NXT_HTTP_NOT_ACCEPTABLE enum valueAndrew Clayton1-0/+1
This will be used by the compression code to signal no requested compression method is available and the client said to not use identity. Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-04-14http: Add a mime_type member to nxt_http_response_tAndrew Clayton1-0/+1
This is to store the MIME type of the response which will be used by the HTTP compression patches as part of determining whether or not to compress the response. Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-04-11Fully initialise the oob struct in nxt_socket_msg_oob_init()Andrew Clayton1-0/+2
valgrind(1) was producing the following alert ==166470== Syscall param sendmsg(msg.msg_control) points to uninitialised byte(s) ==166470== at 0x4AE6514: sendmsg (sendmsg.c:28) ==166470== by 0x42D86C: nxt_sendmsg (nxt_socket_msg.c:32) ==166470== by 0x4FE6695: nxt_unit_sendmsg (nxt_unit.c:6013) ==166470== by 0x4FEB6E2: nxt_unit_ready (nxt_unit.c:963) ==166470== by 0x4FEB6E2: nxt_unit_init (nxt_unit.c:557) ==166470== by 0x4FEEC56: nxt_php_start (nxt_php_sapi.c:507) ==166470== by 0x426BA0: nxt_app_setup (nxt_application.c:1029) ==166470== by 0x403153: nxt_process_do_start (nxt_process.c:718) ==166470== by 0x4042A3: nxt_process_whoami_ok (nxt_process.c:846) ==166470== by 0x407A28: nxt_port_rpc_handler (nxt_port_rpc.c:347) ==166470== by 0x407E42: nxt_port_handler (nxt_port.c:184) ==166470== by 0x40501B: nxt_port_read_msg_process (nxt_port_socket.c:1271) ==166470== by 0x4055B3: nxt_port_read_handler (nxt_port_socket.c:778) ==166470== Address 0x1ffefffc9c is on thread 1's stack ==166470== in frame #3, created by nxt_unit_init (nxt_unit.c:428) ==166470== Uninitialised value was created by a stack allocation ==166470== at 0x4FEABFE: nxt_unit_init (nxt_unit.c:436) This was due to the nxt_send_oob_t oob structure not being fully initialised. Given the name and intention of this function lets *fully* empty-initialise this structure. Link: <https://en.cppreference.com/w/c/language/initialization#Empty_initialization> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-04-11Fully initialise nxt_port_msg_t msg structuresAndrew Clayton1-10/+2
valgrind(1) was producing the following alerts ==166470== Syscall param sendmsg(msg.msg_iov[0]) points to uninitialised byte(s) ==166470== at 0x4AE6514: sendmsg (sendmsg.c:28) ==166470== by 0x42D86C: nxt_sendmsg (nxt_socket_msg.c:32) ==166470== by 0x4FE6695: nxt_unit_sendmsg (nxt_unit.c:6013) ==166470== by 0x4FEB6E2: nxt_unit_ready (nxt_unit.c:963) ==166470== by 0x4FEB6E2: nxt_unit_init (nxt_unit.c:557) ==166470== by 0x4FEEC56: nxt_php_start (nxt_php_sapi.c:507) ==166470== by 0x426BA0: nxt_app_setup (nxt_application.c:1029) ==166470== by 0x403153: nxt_process_do_start (nxt_process.c:718) ==166470== by 0x4042A3: nxt_process_whoami_ok (nxt_process.c:846) ==166470== by 0x407A28: nxt_port_rpc_handler (nxt_port_rpc.c:347) ==166470== by 0x407E42: nxt_port_handler (nxt_port.c:184) ==166470== by 0x40501B: nxt_port_read_msg_process (nxt_port_socket.c:1271) ==166470== by 0x4055B3: nxt_port_read_handler (nxt_port_socket.c:778) ==166470== Address 0x1ffefffc7f is on thread 1's stack ==166470== in frame #3, created by nxt_unit_init (nxt_unit.c:428) ==166470== Uninitialised value was created by a stack allocation ==166470== at 0x4FEABFE: nxt_unit_init (nxt_unit.c:436) ==166690== Syscall param sendmsg(msg.msg_iov[0]) points to uninitialised byte(s) ==166690== at 0x4AE6514: sendmsg (sendmsg.c:28) ==166690== by 0x42D871: nxt_sendmsg (nxt_socket_msg.c:32) ==166690== by 0x4FE6695: nxt_unit_sendmsg (nxt_unit.c:6009) ==166690== by 0x4FE69C8: nxt_unit_port_send (nxt_unit.c:5939) ==166690== by 0x4FE8C77: nxt_unit_request_done (nxt_unit.c:3309) ==166690== by 0x4FEE13B: nxt_php_execute (nxt_php_sapi.c:1257) ==166690== by 0x4FEE2F1: nxt_php_dynamic_request (nxt_php_sapi.c:1128) ==166690== by 0x4FEE79E: nxt_php_request_handler (nxt_php_sapi.c:1023) ==166690== by 0x4FE92AD: nxt_unit_process_ready_req (nxt_unit.c:4846) ==166690== by 0x4FED1B4: nxt_unit_run_once_impl (nxt_unit.c:4605) ==166690== by 0x4FED3AE: nxt_unit_run (nxt_unit.c:4548) ==166690== by 0x4FEEC2A: nxt_php_start (nxt_php_sapi.c:514) ==166690== Address 0x1ffeffea5f is on thread 1's stack ==166690== in frame #3, created by nxt_unit_port_send (nxt_unit.c:5907) ==166690== Uninitialised value was created by a stack allocation ==166690== at 0x4FE8C05: nxt_unit_request_done (nxt_unit.c:3255) These were due to the nxt_port_msg_t msg struct in nxt_unit_ready() and nxt_unit_request_done() not being fully initialised. Whether or not this is an actual problem an obviously correct thing to do is to fully empty-initialise the structure and then we don't need to explicitly set any members to 0 afterwards providing a nice cleanup as well. Link: <https://en.cppreference.com/w/c/language/initialization#Empty_initialization> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-04-09pkg/contrib: Bump wasmtime to 31.0.0Andrew Clayton2-2/+2
This fixes numerous warnings and build failures with rustc 1.86+ Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-04-08rust: Update rust cratesAndrew Clayton3-666/+1018
Update (cargo update) the rust crates for wasm-wasi-component, otel & unitctl. This will fix build issues with wasm-wasi-component & rustc 1.86+. It will also fix dependabot issues in otel and unitctl. Link: <https://github.com/bytecodealliance/wasmtime/issues/10184> Link: <https://github.com/nginx/unit/pull/1585> Link: <https://github.com/nginx/unit/pull/1589> Link: <https://github.com/nginx/unit/pull/1570> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-03-27tests: Fix TLS tests with Python 3.13Andrew Clayton2-0/+2
Python 3.13 sets the VERIFY_X509_STRICT flag by default in create_default_context(). This breaks our TLS tests with dummy certificates. Remove this flag. Thanks to @zfouts for the hint about the flag. As an aside there is another Python 3.13 change which breaks the tests, in that the cgi module has been removed. However there is a legacy-cgi module you can install to get things going again (note this module is unmaintained). E.g. In Fedora 'dnf install python3-legacy-cgi'. Reported-by: Konstantin Pavlov <thresh@nginx.com> Closes: https://github.com/nginx/unit/issues/1545 Link: <https://docs.python.org/3/whatsnew/3.13.html#ssl> Link: <https://docs.python.org/3.13/library/cgi.html> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-03-25tools/unitctl: Fixed waiting for control socketTobias Genannt1-0/+1
Closes: https://github.com/nginx/unit/issues/1577 Signed-off-by: Tobias Genannt <tobias.genannt@gmail.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-03-20auto/cc: gcc: Don't disable -Wunterminated-string-initializationAndrew Clayton1-4/+0
Now that we are able to use the "nonstring" variable attribute to quell this warning, we no longer need to disable it. The good thing is there was never a released version of GCC where the warning couldn't be quelled by the attribute. Fixes: 150378224 ("Fix build with GCC 15") Cc: Alejandro Colomar <alx@kernel.org> Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-03-20Tag various character arrays with NXT_NONSTRINGAndrew Clayton4-6/+6
In Unit we have a number of character arrays which are intentionally not NUL terminated. With GCC 15 this static const char hex[16] = "0123456789ABCDEF"; will trigger a warning like $ gcc -Wextra -c nonstring.c nonstring.c: In function ‘hexit’: nonstring.c:9:37: warning: initializer-string for array of ‘char’ truncates NUL terminator but destination lacks ‘nonstring’ attribute (17 chars into 16 available) [-Wunterminated-string-initialization] 9 | static const char hex[16] = "0123456789ABCDEF"; | ^~~~~~~~~~~~~~~~~~ By adding NXT_NONSTRING like static const char hex[16] NXT_NONSTRING = "0123456789ABCDEF"; we no longer get the warning. Cc: Alejandro Colomar <alx@kernel.org> Co-authored-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-03-19auto/clang: Add a NXT_NONSTRING macroAndrew Clayton2-0/+25
This is a wrapper around __attribute__ ((__nonstring__)). Traditionally this was used to mark char array variables that intentionally lacked a terminating NUL byte, this would then cause warning to either be quelled or emitted for various memory/string functions. GCC 15 introduced a new warning, Wunterminated-string-initialization, which will always warn on things like static const char hex[16] = "0123456789ABCDEF"; However this is very much intentionally not NUL terminated. When the Wunterminated-string-initialization patch went in, the "nonstriong" attribute didn't quell this warning, however a patch has since gone in (prior to the GCC 15 release) to enable this attribute to quell this warning. In Unit we disabled this new warning with an eye to being able to re-enable it again, this patch is the first in a series to do just that. So the above example would become static const char hex[16] NXT_NONSTRING = "0123456789ABCDEF"; Link: <https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=44c9403ed1833ae71a59e84f9e37af3182be0df5> Link: <https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=622968990beee7499e951590258363545b4a3b57> Link: <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178#c21> Cc: Alejandro Colomar <alx@kernel.org> Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-02-21java: websocket: Additional payload length validationMark Thomas1-0/+7
<https://bz.apache.org/bugzilla/show_bug.cgi?id=64563> Patch taken from <https://github.com/apache/tomcat/commit/1c1c77b0efb667cea80b532440b44cea1dc427c3.patch> [ Subject / message tweak - Andrew ] Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-02-21java: websocket: Fix calculation of payload length for > 32bit valuesMark Thomas1-1/+1
Patch taken from <https://github.com/apache/tomcat/commit/1cddae8da4ecb4ac04575d3b5fba2daa2e0c8ead.patch> [ Subject / message tweak - Andrew ] Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-02-21python: Add Django 5.x compatibilityAndrew Clayton1-5/+5
Note: This may not be *specific* to Django 5.x but is where the issue showed up. @codedoga on GitHub reported an issue with Unit and Django 5.x When trying to perform a simple POST/PUT request with body data, Unit was throwing the following error 2025/02/16 11:07:14 [error] 6#6 [unit] #9: Python failed to call 'future.result()' Traceback (most recent call last): File "/usr/local/lib/python3.13/site-packages/django/core/handlers/asgi.py", line 162, in __call__ await self.handle(scope, receive, send) File "/usr/local/lib/python3.13/site-packages/django/core/handlers/asgi.py", line 208, in handle task.result() ~~~~~~~~~~~^^ File "/usr/local/lib/python3.13/site-packages/django/core/handlers/asgi.py", line 239, in listen_for_disconnect assert False, "Invalid ASGI message after request body: %s" % message["type"] ^^^^^ AssertionError: Invalid ASGI message after request body: http.request There is no such issue with Django 4.x The issue was caused when Django started doing an 'async receive()' just after we have handled the initial request and passed it to the application. Django is then looking to see if/when we send it a 'http.disconnect' message. We were not prepared for this and would go through all the motions of handling the request again which would result in the erroneous 'http.request' message. What we need to do is track when we've handled the initial request. We can then use that information coupled with the fact if we get a request with 0 content length then we basically have nothing to do. For this we create a new nxt_py_asgi_http_t member, request_received. We can repurpose 'empty_body_received' for this if we rename it and change where we set it as now if 'request_received' is true then so would 'empty_body_received'. 'empty_body_received' was actually part of a previous commit that was addressing various receive() issues. I've checked that the provided reproducer application still works. Link: <https://github.com/django/django/commit/1d1ddffc27cd55c011298cd09bfa4de3fa73cf7a> Link: <https://github.com/nginx/unit/issues/564> Fixes: 567545213 ("Python: fixing ASGI receive() issues.") Closes: https://github.com/nginx/unit/issues/1561 Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-02-10ci: Update to actions/upload-artifact@v4 in cifuzz.ymlAndrew Clayton1-1/+1
We need to update to the latest version of actions/upload-artifact in cifuzz.yml due to the workflow failing because of Error: This request has been automatically failed because it uses a deprecated version of `actions/upload-artifact: v3`. Learn more: https://github.blog/changelog/2024-04-16-deprecation-notice-v3-of-the-artifact-actions/ Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-02-10http: Fix WebSockets with FirefoxAndrew Clayton1-9/+8
Firefox (going back a couple of years at least) was unable to open a WebSocket connection to Unit due to it sending a Connection header of Connection: keep-alive, Upgrade However in Unit we were expecting only a single value in the header. Fix the 'Connection' parsing in nxt_h1p_connection() to address this. Closes: https://github.com/nginx/unit/issues/772 Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-02-04otel, tools/unitctl: bump the openssl crate from 0.10.68 to 0.10.70dependabot[bot]2-8/+8
Bumps <https://github.com/sfackler/rust-openssl> from 0.10.68 to 0.10.70. Signed-off-by: dependabot[bot] <support@github.com> Link: Release notes <https://github.com/sfackler/rust-openssl/releases> Link: Commits <https://github.com/sfackler/rust-openssl/compare/openssl-v0.10.68...openssl-v0.10.70> [ Tweaked commit message/subject - Andrew ] Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-02-03python: Fix Litestar WebSockets compatibilityAndrew Clayton1-8/+10
It was reported on GitHub that Unit was unable to work with WebSockets under Litestar Python applications. This was due to Unit sending a 'method' variable in the WebSocket's connection scope, which Litestar was interpreting as being a normal HTTP connection. The ASGI WebSocket specification makes no mention about setting a 'method', so let's not send it on WebSockets. Also tested this change with basic ASGI WebSockets and FastAPI WebSockets and obviously pytests still pass. Closes: https://github.com/nginx/unit/issues/1507 Link: <https://asgi.readthedocs.io/en/latest/specs/www.html#websocket-connection-scope> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-02-03Fix build with GCC 15Andrew Clayton1-0/+4
The upcoming GCC 15 release introduces a new compiler warning, Wunterminated-string-initialization. This is intended to catch things like static const u_char hex[16] = "0123456789ABCDEF"; Where we are creating a character array from a string literal, but the specified size is not enough for the terminating NUL byte. In the above example that is intended as it is used as a lookup table and only the individual indices are accessed. As it happens, Unit uses the above idiom in a few places, triggering this warning (which we treat as an error by default). While I don't like disabling compiler warnings, lets just disable this one temporarily, as there is a patch in the works to make the "nonstring" variable attribute quell this warning. We just disable this on GCC as this isn't in Clang and we don't need to worry about older compilers as GCC silently ignores unknown -Wno-* options. Link: <https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=44c9403ed1833ae71a59e84f9e37af3182be0df5> Link: <https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Common-Variable-Attributes.html> Link: <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178#c21> Cc: Alejandro Colomar <alx@kernel.org> Reviewed-by: Alejandro Colomar <alx@kernel.org> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-01-22ruby: Fix build failures with Ruby 3.4Andrew Clayton1-5/+23
Ruby 3.4 started to actually mark some deprecated functions as *deprecated* now resulting in compiler warnings (which due to -Werror we treat as errors and thus the build fails). The *new* functions were actually introduced back in Ruby 1.9.2, so have been around for quite some time. We claim support for Ruby 2.0 onwards so this is more than fine. The new API replaces the old 'mark' and 'free' parameters with a struct that allows for more fine tuning/configuration. We never made use of either of those parameters and so the only members of this struct we *need* to set is the structure wrapper name and the dsize function pointer which is passed a pointer to the underlying wrapped structure to calculate its memory usage. While this is *not* required the documentation *recommends* setting it (though it doesn't say how it's used). Ruby pytests still pass after this change... Closes: https://github.com/nginx/unit/issues/1525 Link: <https://bugs.ruby-lang.org/issues/19998> Link: <https://docs.ruby-lang.org/en/3.4/extension_rdoc.html#label-C+struct+to+Ruby+object> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-01-14Update copyright noticeAndrew Clayton8-58/+65
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-01-14http: add `.mjs` extension to default mime typesTal Kedar1-0/+1
Associate file extension `.mjs` with `application/javascript`. Context: common output of static site generators. There's little risk of ambiguity for this extension, so might as well support it out of the box. [ Subject tweak - Andrew ] Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-01-10auto/make: Fix various issues with building OTELAndrew Clayton1-18/+20
There were at least a couple of issues with building OTEL support. It only worked with GNU make due to the use of ifeq, even gmake had some issues. Debug builds were broken due to trying to pass --debug to cargo which is the default and isn't a valid option. This 'fixes' things by doing 'release' builds of OTEL by default. Passing D=1 to make will generate 'debug' builds but this as previously with D= etc, only works with GNU make. We make use of the '--emit link=' rustc option to place the libotel.a static library into build/lib This is good, it consolidates the static libraries into one place and it simplifies the build scripts. While we're at it pretty print the cargo command by default. Fixes: 9d3dcb800 ("otel: add build tooling to include otel code") Link: <https://github.com/nginx/unit/pull/1520#issuecomment-2556265063> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-01-10auto/otel: don't look for OpenSSL on DarwinKonstantin Pavlov1-23/+39
Rust code relies on macOS-provided frameworks for TLS. Fixes: 9d3dcb800 ("otel: add build tooling to include otel code") [ Tweaked subject prefix. Some minor tweaks for current changes. - Andrew ] Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-01-10auto/make: Add missing NXT_OTEL_LIB_STATIC to some C testsRemi Collet1-8/+12
Fixes: 9d3dcb800 ("otel: add build tooling to include otel code") [ Commit subject, s/NXT_OTEL_LIB_LOC/NXT_OTEL_LIB_STATIC/ and placement of NXT_OTEL_LIB_STATIC tweaked as per @thresheek - Andrew ] Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-01-10auto/make, otel: fix linking on macOS and UbuntuKonstantin Pavlov1-4/+6
The static library is supposed to be specified prior to its dependencies. Also, no need to put an otel static library inside libnxt static library, as we explicitely link unit binary with otel static library anyway. This fixes the following build problems: - macOS: Finished `release` profile [optimized] target(s) in 58.07s AR build/lib/libnxt.a LD build/sbin/unitd ld: archive member 'libotel.a' not a mach-o file in '/private/tmp/unit-20241219-8965-yb46xp/build/lib/libnxt.a' clang: error: linker command failed with exit code 1 (use -v to see invocation) - Ubuntu 22 (./configure --otel): LD build/sbin/unitd cc -Wl,-E -o build/sbin/unitd -pipe -fPIC -fvisibility=hidden -fno-strict-overflow -funsigned-char -std=gnu11 -O -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -fno-strict-aliasing -Wmissing-prototypes -Werror -g \ build/src/nxt_main.o build/lib/libnxt.a \ -lm -lrt -lpthread \ \ -lpcre2-8 -lssl -lcrypto src/otel/target/release/libotel.a /usr/bin/ld: src/otel/target/release/libotel.a(reqwest-97d1376dfb77d784.reqwest.cb371ce8e1e3945e-cgu.04.rcgu.o): in function `core::ptr::drop_in_place<alloc::vec::Vec<reqwest::tls::Certificate>>': reqwest.cb371ce8e1e3945e-cgu.04:(.text._ZN4core3ptr69drop_in_place$LT$alloc..vec..Vec$LT$reqwest..tls..Certificate$GT$$GT$17h9b62679cc7161be5E+0x30): undefined reference to `X509_free' Fixes: 9d3dcb800 ("otel: add build tooling to include otel code") [ Tweaked subject prefix. s/NXT_OTEL_LIB_LOC/NXT_OTEL_LIB_STATIC/ - Andrew ] Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-01-10auto/make: s/NXT_OTEL_LIB_LOC/NXT_OTEL_LIB_STATIC/Andrew Clayton1-10/+10
This better matches existing naming convention, e.g NXT_LIB_STATIC Fixes: 9d3dcb800 ("otel: add build tooling to include otel code") Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-01-10auto/otel: Make use of nxt_feature_nameAndrew Clayton1-7/+1
When building with --otel on macOS for example I was seeing compile failures with the cpu_set_t stuff which should only be used under Linux. It turned out that despite checking for Linux sched_getaffinity() ... not found we were getting #ifndef NXT_HAVE_LINUX_SCHED_GETAFFINITY #define NXT_HAVE_LINUX_SCHED_GETAFFINITY 1 #endif in build/include/nxt_auto_config.h It seems this was due to the . auto/feature in auto/otel, this check happens right after the above. Without having nxt_feature_name=NXT_HAVE_OTEL set. Instead we were adding the define for that manually. Doing auto/feature without having a nxt_feature_name must have used the last set one and enabled it. Set nxt_feature_name and remove the manual editing of nxt_auto_config.h Fixes: 9d3dcb800 ("otel: add build tooling to include otel code") Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2025-01-08otel: remove deadcodeAva Hahn1-10/+1
The superfluous else condition in nxt_otel_propagate_header was dead code. This commit removes it. Signed-off-by: Ava Hahn <a.hahn@f5.com>
2025-01-08otel: fix segfaults when otel not configuredAva Hahn1-6/+9
This commit adds NULL checks for the request->otel object that were missed in the Traceparent and Tracestate routines. Closes: https://github.com/nginx/unit/issues/1523 Closes: https://github.com/nginx/unit/issues/1526 Fixes: 9d3dcb800 ("otel: add build tooling to include otel code") Signed-off-by: Ava Hahn <a.hahn@f5.com>
2024-12-19Version bumpAndrew Clayton2-2/+34
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-12-19Add 1.34.0 CHANGES1.34.0Andrew Clayton1-0/+10
This is autogenerated from docs/changes.xml by $ make -C docs/ changes && mv build/CHANGES . Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-12-19docs/changes.xml: Add 1.34.0 changelog entriesAndrew Clayton1-4/+23
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-12-18pkg/docker: Update dockerfiles for 1.34.0Andrew Clayton17-91/+428
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-12-18docs/unit-openapi.yaml: Update version for 1.34.0Andrew Clayton1-1/+1
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-12-18tools/unitctl: Update for version 1.34.0Andrew Clayton6-8/+8
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-12-18.mailmap: Add an entry for IgorAndrew Clayton1-0/+1
You can always see the original names/addresses used by passing --no-mailmap to the various git commands. See gitmailmap(5) Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
generated by cgit (git 2.34.1) at 2025-12-06 05:28:36 +0000