| Age | Commit message (Collapse) | Author | Files | Lines |
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This is autogenerated from docs/changes.xml by
$ make -C docs/ changes && mv build/CHANGES .
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>
|
|
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
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>
|
|
|
|
(cherry picked from commit 4ca64ff4cd71334c7661e487f7e7953c20e04154)
Signed-off-by: Konstantin Pavlov <thresh@nginx.com>
|
|
|
|
|
|
|
|
|
|
Run 'cargo update' to get the latest version of the required crates in
preparation for the 1.34.0 release.
This resolves a dependabot notification regarding 'idna'.
Link: <https://github.com/nginx/unit/security/dependabot/13>
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.34.0 release.
This resolves a dependabot notification regarding 'idna'.
Link: <https://github.com/nginx/unit/security/dependabot/14>
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.34.0 release.
The rustls update fixes a panic in `rustls::server::Acceptor::accept()`,
but Unit does not use this code path and was not affected.
Link: <https://rustsec.org/advisories/RUSTSEC-2024-0399.html>
Link: <https://github.com/nginx/unit/security/dependabot/11>
Closes: <https://github.com/nginx/unit/issues/1503>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
For no real reason other than to be on the latest release for the next
release of Unit...
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
@thresheek reported an issue trying to configure OTEL support on Amazon
Linux 2
checking for OTEL requirements:
- checking for rust compiler ... found
- checking for cargo ... found
- checking for OpenSSL library ... found
Package openssl was not found in the pkg-config search path.
Perhaps you should add the directory containing `openssl.pc'
to the PKG_CONFIG_PATH environment variable
No package 'openssl' found
We successfully built the test program with '-lssl -lcrypto', but then
tried to use 'pkg-config openssl --cflags --libs' to override
NXT_OTEL_LIBS.
On Amazon Linux2 there is no openssl.pc, they have a openssl11.pc.
Let's just remove the pkg-config check, if we get here, we have
successfully built with '-lssl -lcrypto', so just go with that (it also
matches what we do in auto/ssltls).
Reported-by: Konstantin Pavlov <thresh@nginx.com>
Closes: https://github.com/nginx/unit/issues/1510
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
While at it, removed support for Fedora 39 as it's EOL.
|
|
In 4.20, rpm changed the way build roots are named. Our packaging
relies on the symlinks being created as a part of a rule to make sure
targets are being built correctly.
This patch implements (a hacky) way to check what the build root should
be named on a currently running rpm version and adjusts the symlinks
accordingly.
|
|
|
|
When compiling OTEL support with rustc 1.83.0 we started getting the
following warning
Compiling otel v0.1.0 (/home/andrew/src/unit/src/otel)
warning: creating a mutable reference to mutable static is discouraged
--> src/lib.rs:42:9
|
42 | SPAN_TX.take();
| ^^^^^^^^^^^^^^ mutable reference to mutable static
|
= note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2024/static-mut-references.html>
= note: mutable references to mutable statics are dangerous; it's undefined behavior if any other pointer to the static is used or if any other reference is created for the static while the mutable reference lives
= note: `#[warn(static_mut_refs)]` on by default
warning: `otel` (lib) generated 1 warning
Finished `release` profile [optimized] target(s) in 1m 07s
However it *seems* our usage is OK, so we can disable this warning
(which it seems will soon turn into a hard error), fortunately we only
need to disable it for the nxt_otel_rs_span_tx() function.
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
|
|
This just builds the OTEL stuff for the Fedora Rawhide and Alpine Edge
distributions.
If we ever get test cases covering OTEL we can figure out the best way
to do it in the ci.yaml, but right now I don't see the point in building
OTEL in every test configuration there...
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|