| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This is mainly just to be on the latest version for the next release of
Unit.
This required some changes to the language module as described here
<https://github.com/bytecodealliance/wasmtime/pull/10016>.
We also add unnecessary_transmutes to the list of allowed linters to
quell warnings like
warning: unnecessary transmute
--> /home/andrew/src/unit/src/wasm-wasi-component/target/debug/build/wasm-wasi-component-9ae3c2c94201e6be/out/bindings.rs:440:13
|
440 | ... ::std::mem::transmute(self._bitfield_1.get(0usize, 24u8) as u32)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: replace this with: `u32::cast_signed(self._bitfield_1.get(0usize, 24u8) as u32)`
|
= note: `#[warn(unnecessary_transmutes)]` on by default
Also, because this is new in rustc 1.88, to avoid warnings on older
compilers the simplest thing is to just add unknown_lints to the list.
Link: <https://lists.gnu.org/archive/html/qemu-rust/2025-07/msg00006.html>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Run 'cargo update' to get the latest version of the required crates in
preparation for the 1.35.0 release.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Run 'cargo update' to get the latest version of the required crates in
preparation for the 1.35.0 release.
This resolves a dependabot notification regarding 'crossbeam-channel'.
Link: <https://github.com/nginx/unit/security/dependabot/26>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Run 'cargo update' to get the latest version of the required crates in
preparation for the 1.35.0 release.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
The Perl, PHP, Python, Ruby & Java language modules all hard code
SERVER_PORT to "80".
Adjust them to bring them in line with the wasm language module which
uses r->local_port (I.e. the port unit accepted the connection on).
Closes: https://github.com/nginx/unit/issues/761
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
It fixes losing context in response in cases when there are 2 or more
headers with the same name. The prev implementation used to use foreach
function which uses local lexical environment and did not find
this.headers_len locally, which causes crash of the http server module.
It was replaced with a for loop in order to make access for this.headers_len
variable and improve performance of calculation.
Closes: https://github.com/nginx/unit/issues/1621
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
GCC 15 enabled "-Wzero-as-null-pointer-constant" for C, which checks for
places where '0' has been used as a null pointer constant.
This showed a few places in Unit where we were using '0' instead of the
more correct NULL macro. E.g.
$ make -j4 EXTRA_CFLAGS=-Wzero-as-null-pointer-constant
...
src/nxt_buf.c: In function ‘nxt_buf_mmap_alloc’:
src/nxt_buf.h:192:21: error: zero as null pointer constant [-Werror=zero-as-null-pointer-constant]
192 | (bm)->start = 0; \
| ^
src/nxt_buf.c:135:9: note: in expansion of macro ‘nxt_buf_mem_set_size’
135 | nxt_buf_mem_set_size(&b->mem, size);
| ^~~~~~~~~~~~~~~~~~~~
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Seems OpenJDK 17 is no longer available in Debian testing.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This bumps the minimum required version of njs to 0.9.0
Cc: Sergey A. Osokin <sergey.osokin@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This just does a build test of building Unit with support for zlib
(deflate & gzip), zstd and brotli HTTP compression.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
You asked for a specific compression library, be clear when it isn't
found.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
-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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
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>
|
|
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>
|
|
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>
|
|
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This adds support for both deflate & gzip compressors.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
This fixes numerous warnings and build failures with rustc 1.86+
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
<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>
|
|
Patch taken from <https://github.com/apache/tomcat/commit/1cddae8da4ecb4ac04575d3b5fba2daa2e0c8ead.patch>
[ Subject / message tweak - Andrew ]
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
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>
|
|
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>
|
|
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>
|
