summaryrefslogtreecommitdiffhomepage
AgeCommit message (Collapse)AuthorFilesLines
2023-05-25Tests: unified setup method usage.Andrei Zeliankou15-93/+113
To make fixtures accessible inside of setup methods in tests all these methods are renamed to the "setup_method_fixture" and decorated by autouse flag. Also all setup methods moved to the top of the files.
2023-05-25Tests: removed unused variables.Andrei Zeliankou34-91/+87
2023-05-25Tests: fixed incorrect pointer assignment.Alejandro Colomar1-2/+2
If we don't update the pointer before copying the request body, then we get the behavior shown below. After this patch, "foo\n" is rightly appended at the end of the response body. Request: "GET / HTTP/1.1\r\nHost: _\nContent-Length: 4\n\nfoo\n" Response body: """ Hello world! foo est data: Method: GET Protocol: HTTP/1.1 Remote addr: 127.0.0.1 Local addr: 127.0.0.1 Target: / Path: / Fields: Host: _ Content-Length: 4 Body: """ Fixes: 1bb22d1e922c ("Unit application library.") Reviewed-by: Andrew Clayton <a.clayton@nginx.com> Signed-off-by: Alejandro Colomar <alx@nginx.com>
2023-05-24Updated copyright notice.Andrei Zeliankou9-27/+75
2023-05-24Version bump.Andrei Zeliankou2-2/+44
2023-05-21Using names in .mailmap.Alejandro Colomar1-2/+2
In this case, Andrew always committed under the same name, so it's not strictly necessary. This is for consistency, so that it's clearer whose is an email address. It also makes it easier to sort the names alphabetically. Reviewed-by: Andrew Clayton <a.clayton@nginx.com> Signed-off-by: Alejandro Colomar <alx@nginx.com>
2023-05-21Added Alex to .mailmap.Alejandro Colomar1-0/+2
Reviewed-by: Andrew Clayton <a.clayton@nginx.com> Signed-off-by: Alejandro Colomar <alx@nginx.com>
2023-05-21Added back deprecated options to unitd.Alejandro Colomar1-0/+31
We renamed the options recently, with the intention of keeping the old names as supported but deprecated for some time, before removal. This was done with the configure script options, but in the unitd binary, we accidentally removed the old names, causing some unintended breakage. Keep support for the old names, albeit with a deprecation message to stderr, for some time, until we decide to remove them. Fixes: 5a37171f733f ("Added default values for pathnames.") Closes: <https://github.com/nginx/unit/issues/876> Reported-by: El RIDO <elrido@gmx.net> Acked-by: Liam Crilly <liam@nginx.com> Acked-by: Artem Konev <a.konev@f5.com> Acked-by: Timo Stark <t.stark@nginx.com> Reviewed-by: Andrew Clayton <a.clayton@nginx.com> Cc: Andrei Zeliankou <zelenkov@nginx.com> Signed-off-by: Alejandro Colomar <alx@nginx.com>
2023-05-19Tests: added tests for "server_version" option.Andrei Zeliankou1-0/+15
2023-05-19Tests: added ASGI application with IPv6 address test.Andrei Zeliankou1-0/+9
2023-05-18Python: Fix ASGI applications accessed over IPv6.Andrew Clayton1-11/+3
There are a couple of reports on GitHub about issues accessing Python ASGI based applications over IPv6. A request over IPv6 would result in an error like 2023/05/13 17:49:12 [alert] 47202#47202 [unit] #10: Python failed to create 'client' pair 2023/05/13 17:49:12 [alert] 47202#47202 [unit] Python failed to call 'loop.call_soon' ValueError: invalid literal for int() with base 10: 'db8:1:1:1ee7:dead:beef:cafe' The above error was the direct cause of the following exception: Traceback (most recent call last): File "/usr/lib64/python3.11/asyncio/base_events.py", line 765, in call_soon handle = self._call_soon(callback, args, context) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib64/python3.11/asyncio/base_events.py", line 781, in _call_soon handle = events.Handle(callback, args, self, context) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ SystemError: <class 'asyncio.events.Handle'> returned a result with an exception set This issue occurred in the nxt_py_asgi_create_ip_address() function where it tries to create an IP address / port number pair. It does this by looking for the first ':' in the address and taking everything after it as the port number. Like in the above error message, if we tried to access the server @ 2001:db8:1:1:1ee7:dead:beef:cafe, then we'd end up with the port number as 'db8:1:1:1ee7:dead:beef:cafe'. There are two issues with this 1) The IP address and port number are already flowed through separately. 2) Even if (1) wasn't true, it would still be broken for IPv6 as we'd expect to a get an address literal like [2001:db8:1:1:1ee7:dead:beef:cafe]:8080, however there was no code to handle the []'s. The fix is to simply not try looking for a port number. We pass a port number into this function to use in the case where we don't find a port number, we never will... A further cleanup would be to flow through the server port number when creating the 'server pair' PyTuple, rather than just using the hard coded 80. Closes: <https://github.com/nginx/unit/issues/793> Closes: <https://github.com/nginx/unit/issues/874> Reviewed-by: Alejandro Colomar <alx@nginx.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2023-05-10Fixed broken links in README.Artem Konev1-4/+4
2023-05-10Added the initial version of the OpenAPI specification.Artem Konev2-6/+6350
2023-05-10Unit 1.30.0 release.Andrei Zeliankou1-0/+1
2023-05-10Merged with the 1.29 branch.1.30.0Andrei Zeliankou1-2/+1
2023-05-10Added version 1.30.0 CHANGES.Andrei Zeliankou2-2/+30
2023-05-10Edited "changes.xml" for the 1.30.0 release.Andrei Zeliankou1-4/+35
2023-05-10Toned down proxy messaging in README.Artem Konev1-2/+1
2023-05-10Tests: added tests for NJS loadable modules.Andrei Zeliankou6-15/+133
2023-05-09Regenerated dockerfiles.Konstantin Pavlov11-425/+477
2023-05-09Docker: show welcome page on port 80 when entrypoint.d is empty.Liam Crilly5-33/+136
The entrypoint script now performs a default configuration when no useful files are found in /docker-entrypoint.d/ The default configuration serves a welcome page in response to all requests, using Markdown unless text/html is sent in the Accept header. This provides a useful 'hello world' experience when running a Unit container for the first time.
2023-05-05Docker: tagged minimal variant as latest.Konstantin Pavlov1-1/+5
2023-05-05Docker: Makefile housekeeping.Konstantin Pavlov1-5/+2
2023-05-05Docker: added a way to generate multiple versions of an image.Konstantin Pavlov1-23/+30
2023-05-03Packages: added Ubuntu 23.04 "lunar" support.Konstantin Pavlov6-1/+177
2023-05-09Docker: add support for JavaScript modules.Liam Crilly1-1/+7
2023-05-08NJS: supported loadable modules.Zhidao HONG16-50/+1591
2023-05-09Tests: added tests for the URI rewrite.Andrei Zeliankou1-0/+219
2023-04-20HTTP: added basic URI rewrite.Zhidao HONG11-11/+167
This commit introduced the basic URI rewrite. It allows users to change request URI. Note the "rewrite" option ignores the contained query if any and the query from the request is preserverd. An example: "routes": [ { "match": { "uri": "/v1/test" }, "action": { "return": 200 } }, { "action": { "rewrite": "/v1$uri", "pass": "routes" } } ] Reviewed-by: Alejandro Colomar <alx@nginx.com>
2023-05-08Docs: removed incorrect Pp call in unitd.8.Alejandro Colomar1-1/+0
Pp is used to separate paragraphs, not to introduce them. A Pp macro call right after Sh is wrong, and it is ignored by the formatter, which reports a warning about it. Signed-off-by: Alejandro Colomar <alx@nginx.com>
2023-05-08Docs: using appropriate mdoc(7) macros for URIs in unitd.8.Alejandro Colomar1-6/+3
Reviewed-by: Artem Konev <a.konev@f5.com> Signed-off-by: Alejandro Colomar <alx@nginx.com>
2023-05-08Docs: changed Authors section to Copyright section in unitd.8.Alejandro Colomar1-2/+4
The Authors section is meant to list the main authors. However, the section only contained the copyright notice, so the Copyright section seems more appropriate. While we change that, it makes sense to also specify the license, and update the copyright year. Reviewed-by: Liam Crilly <liam@nginx.com> Reviewed-by: Artem Konev <a.konev@f5.com> Signed-off-by: Alejandro Colomar <alx@nginx.com>
2023-05-08Docs: updated unitd.8 date.Alejandro Colomar1-1/+1
We've applied significant changes to the page, so let's update the date. While we're at it, let's change it to use ISO 8601 format for the date. Reviewed-by: Artem Konev <a.konev@f5.com> Signed-off-by: Alejandro Colomar <alx@nginx.com>
2023-05-08Docs: setting the project name in unitd.8.Alejandro Colomar1-1/+1
Not setting it produces the default value of 'BSD' or 'GNU', depending on the software formatting the manual page. We're neither, so let's specify our project name. See groff_mdoc(7). While mandoc_mdoc(7) formally says that .Os is only for the operating system, and not for the package name, that's an oversimplification, and only meant for software inherent to the OS. For portable software, mandoc(1)'s (and OpenBSD's) maintainer Ingo Schwarze agreed that it is more sensible to specify the project name (and optionally, the version). Reviewed-by: Artem Konev <a.konev@f5.com> Signed-off-by: Alejandro Colomar <alx@nginx.com>
2023-05-08Docs: documenting the renamed directory flags in unitd.8.Alejandro Colomar1-4/+4
Reviewed-by: Artem Konev <a.konev@f5.com> Signed-off-by: Alejandro Colomar <alx@nginx.com>
2023-05-08Docs: not using shouty caps in unitd.8.Alejandro Colomar1-10/+10
There was a recent unanimous agreement by maintainers of groff, mandoc, the Linux man-pages, and other relevant programmers, that manual pages should not use uppercase unnecessarily. Use of uppercase in the title and in the section's titles dates from before one could use bold, italics, and other such formatting, so that it was the way of giving more importance to certain parts of a page. Nowadays, we use bold, so uppercase is unnecessary. Moreover, using uppercase in the title is bad, since it removes information. If we keep the exact casing used in the program (or function) name, we provide more information. And anyway, if users want to read in uppercase, they can program certain mdoc(7) or man(7) macros to transform their arguments into uppercase. This could be done via </etc/groff/mdoc.local> and </etc/groff/man.local>. There's a plan of transforming OpenBSD pages and the Linux man-pages to stop using uppercase. Other projects may join. That will likely happen in the following months. Let's align with this. Reviewed-by: Artem Konev <a.konev@f5.com> Signed-off-by: Alejandro Colomar <alx@nginx.com>
2023-05-08Docs: removed '-v' from unitd.8.Alejandro Colomar1-2/+2
This short option is not really supported. Probably it was just a typo. Reviewed-by: Artem Konev <a.konev@f5.com> Signed-off-by: Alejandro Colomar <alx@nginx.com>
2023-05-08Docs: moved uintd.8 to man8/ subdirectory.Alejandro Colomar5-6/+6
Reviewed-by: Artem Konev <a.konev@f5.com> Signed-off-by: Alejandro Colomar <alx@nginx.com>
2023-04-12Docker: made curl fail with non-zero exit code on server errors.Konstantin Pavlov1-1/+1
2023-04-25Allow to remove the version string in HTTP responses.Andrew Clayton4-3/+22
Normally Unit responds to HTTP requests by including a header like Server: Unit/1.30.0 however it can sometimes be beneficial to withhold the version information and in this case just respond with Server: Unit This patch adds a new "settings.http" boolean option called server_version, which defaults to true, in which case the full version information is sent. However this can be set to false, e.g "settings": { "http": { "server_version": false } }, in which case Unit responds without the version information as the latter example above shows. Link: <https://www.ietf.org/rfc/rfc9110.html#section-10.2.4> Closes: <https://github.com/nginx/unit/issues/158> Reviewed-by: Alejandro Colomar <alx@nginx.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2023-04-25Decouple "Unit" from NXT_SERVER.Andrew Clayton1-1/+2
Split out the "Unit" name from the NXT_SERVER #define into its own NXT_NAME #define, then make NXT_SERVER a combination of that and NXT_VERSION. This is required for a subsequent commit where we may want the server name on its own. Reviewed-by: Alejandro Colomar <alx@nginx.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2023-04-24Remove an erroneous semi-colon.Andrew Clayton1-1/+1
Reviewed-by: Alejandro Colomar <alx@nginx.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2023-04-24Don't conflate the error variable in nxt_kqueue_poll().Andrew Clayton1-3/+4
In nxt_kqueue_poll() error is declared as a nxt_bool_t aka unsigned int (on x86-64 anyway). It is used both as a boolean and as the return storage for a bitwise AND operation. This has potential to go awry. If nxt_bool_t was changed to be a u8 then we would have the following issue gcc12 -c -pipe -fPIC -fvisibility=hidden -O -W -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wmissing-prototypes -Werror -g -O2 -I src -I build -I/usr/local/include -o build/src/nxt_kqueue_engine.o -MMD -MF build/src/nxt_kqueue_engine.dep -MT build/src/nxt_kqueue_engine.o src/nxt_kqueue_engine.c src/nxt_kqueue_engine.c: In function 'nxt_kqueue_poll': src/nxt_kqueue_engine.c:728:17: error: overflow in conversion from 'int' to 'nxt_bool_t' {aka 'unsigned char'} changes value from '(int)kev->flags & 16384' to '0' [-Werror=overflow] 728 | error = (kev->flags & EV_ERROR); | ^ cc1: all warnings being treated as errors EV_ERROR has the value 16384, after the AND operation error holds 16384, however this overflows and wraps around (64 times) exactly to 0. With nxt_bool_t defined as a u32, we would have a similar issue if EV_ERROR ever became UINT_MAX + 1 (or a multiple thereof)... Rather than conflating the use of error, keep error as a boolean (it is used further down the function) but do the AND operation inside the if (). Reviewed-by: Alejandro Colomar <alx@nginx.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2023-04-24Remove a bunch of dead code.Andrew Clayton22-4948/+0
This removes a bunch of unused files that would have been touched by subsequent commits that switch to using nxt_bool_t (AKA unit6_t) in structures. In auto/sources we have NXT_LIB_SRC0=" \ src/nxt_buf_filter.c \ src/nxt_job_file.c \ src/nxt_stream_module.c \ src/nxt_stream_source.c \ src/nxt_upstream_source.c \ src/nxt_http_source.c \ src/nxt_fastcgi_source.c \ src/nxt_fastcgi_record_parse.c \ \ src/nxt_mem_pool_cleanup.h \ src/nxt_mem_pool_cleanup.c \ " None of these seem to actually be used anywhere (other than within themselves). That variable is _not_ referenced anywhere else. Also remove the unused related header files: src/nxt_buf_filter.h, src/nxt_fastcgi_source.h, src/nxt_http_source.h, src/nxt_job_file.h, src/nxt_stream_source.h and src/nxt_upstream_source.h Also, these files do not seem to be used, no mention under auto/ or build/ src/nxt_file_cache.c src/nxt_cache.c src/nxt_job_file_cache.c src/nxt_cache.h is #included in src/nxt_main.h, but AFAICT is not actually used. With all the above removed $ ./configure --openssl --debug --tests && make -j && make -j tests && make libnxt all builds. Buildbot passes. NOTE: You may need to do a 'make clean' before the next build attempt. Reviewed-by: Alejandro Colomar <alx@nginx.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2023-04-15Tools: setup-unit: unified repeated code.Alejandro Colomar1-9/+7
Instead of doing the same operation in each subcommand, do it once in the parent. Reviewed-by: Andrew Clayton <a.clayton@nginx.com> Signed-off-by: Alejandro Colomar <alx@nginx.com>
2023-04-11contrib: updated njs to 0.7.12.Konstantin Pavlov3-3/+6
2023-04-12HTTP: optimizing $request_line.Alejandro Colomar6-45/+24
Don't reconstruct a new string for the $request_line from the parsed method, target, and HTTP version, but rather keep a pointer to the original memory where the request line was received. This will be necessary for implementing URI rewrites, since we want to log the original request line, and not one constructed from the rewritten target. This implementation changes behavior (only for invalid requests) in the following way: Previous behavior was to log as many tokens from the request line as were parsed validly, thus: Request -> access log ; error log "GET / HTTP/1.1" -> "GET / HTTP/1.1" OK ; = "GET / HTTP/1.1" -> "GET / HTTP/1.1" [1] ; = "GET / HTTP/2.1" -> "GET / HTTP/2.1" OK ; = "GET / HTTP/1." -> "GET / HTTP/1." [2] ; "GET / HTTP/1. [null]" "GET / food" -> "GET / food" [2] ; "GET / food [null]" "GET / / HTTP/1.1" -> "GET / / HTTP/1.1" [2] ; = "GET / / HTTP/1.1" -> "GET / / HTTP/1.1" [2] ; = "GET food HTTP/1.1" -> "GET" ; "GET [null] [null]" "OPTIONS * HTTP/1.1" -> "OPTIONS" [3] ; "OPTIONS [null] [null]" "FOOBAR baz HTTP/1.1"-> "FOOBAR" ; "FOOBAR [null] [null]" "FOOBAR / HTTP/1.1" -> "FOOBAR / HTTP/1.1" ; = "get / HTTP/1.1" -> "-" ; " [null] [null]" "" -> "-" ; " [null] [null]" This behavior was rather inconsistent. We have several options to go forward with this patch: - NGINX behavior. Log the entire request line, up to '\r' | '\n', even if it was invalid. This is the most informative alternative. However, RFC-complying requests will probably not send invalid requests. This information would be interesting to users where debugging requests constructed manually via netcat(1) or a similar tool, or maybe for debugging a client, are important. It might be interesting to support this in the future if our users are interested; for now, since this approach requires looping over invalid requests twice, that's an overhead that we better avoid. - Previous Unit behavior This is relatively fast (almost as fast as the next alternative, the one we chose), but the implementation is ugly, in that we need to perform the same operation in many places around the code. If we want performance, probably the next alternative is better; if we want to be informative, then the first one is better (maybe in combination with the third one too). - Chosen behavior Only logging request lines when the request is valid. For any invalid request, or even unsupported ones, the request line will be logged as "-". Thus: Request -> access log [4] "GET / HTTP/1.1" -> "GET / HTTP/1.1" OK "GET / HTTP/1.1" -> "GET / HTTP/1.1" [1] "GET / HTTP/2.1" -> "-" [3] "GET / HTTP/1." -> "-" "GET / food" -> "-" "GET / / HTTP/1.1" -> "GET / / HTTP/1.1" [2] "GET / / HTTP/1.1" -> "GET / / HTTP/1.1" [2] "GET food HTTP/1.1" -> "-" "OPTIONS * HTTP/1.1" -> "-" "FOOBAR baz HTTP/1.1"-> "-" "FOOBAR / HTTP/1.1" -> "FOOBAR / HTTP/1.1" "get / HTTP/1.1" -> "-" "" -> "-" This is less informative than previous behavior, but considering how inconsistent it was, and that RFC-complying agents will probably not send us such requests, we're ready to lose that information in the log. This is of course the fastest and simplest implementation we can get. We've chosen to implement this alternative in this patch. Since we modified the behavior, this patch also changes the affected tests. [1]: Multiple successive spaces as a token delimiter is allowed by the RFC, but it is discouraged, and considered a security risk. It is currently supported by Unit, but we will probably drop support for it in the future. [2]: Unit currently supports spaces in the request-target. This is a violation of the relevant RFC (linked below), and will be fixed in the future, and consider those targets as invalid, returning a 400 (Bad Request), and thus the log lines with the previous inconsistent behavior would be changed. [3]: Not yet supported. [4]: In the error log, regarding the "log_routes" conditional logging of the request line, we only need to log the request line if it was valid. It doesn't make sense to log "" or "-" in case that the request was invalid, since this is only useful for understanding decisions of the router. In this case, the access log is more appropriate, which shows that the request was invalid, and a 400 was returned. When the request line is valid, it is printed in the error log exactly as in the access log. Link: <https://datatracker.ietf.org/doc/html/rfc9112#section-3> Suggested-by: Liam Crilly <liam@nginx.com> Reviewed-by: Zhidao Hong <z.hong@f5.com> Cc: Timo Stark <t.stark@nginx.com> Cc: Andrei Zeliankou <zelenkov@nginx.com> Cc: Andrew Clayton <a.clayton@nginx.com> Cc: Artem Konev <a.konev@f5.com> Signed-off-by: Alejandro Colomar <alx@nginx.com>
2023-04-11Docker: fixed a typo.Konstantin Pavlov1-1/+1
2023-04-11Add per-application logging.Andrew Clayton5-0/+81
Currently when running in the foreground, unit application processes will send stdout to the current TTY and stderr to the unit log file. That behaviour won't change. When running as a daemon, unit application processes will send stdout to /dev/null and stderr to the unit log file. This commit allows to alter the latter case of unit running as a daemon, by allowing applications to redirect stdout and/or stderr to specific log files. This is done via two new application options, 'stdout' & 'stderr', e.g "applications": { "myapp": { ... "stdout": "/path/to/log/unit/app/stdout.log", "stderr": "/path/to/log/unit/app/stderr.log" } } These log files are created by the application processes themselves and thus the log directories need to be writable by the user (and or group) of the application processes. E.g $ sudo mkdir -p /path/to/log/unit/app $ sudo chown APP_USER /path/to/log/unit/app These need to be setup before starting unit with the above config. Currently these log files do not participate in log-file rotation (SIGUSR1), that may change in a future commit. In the meantime these logs can be rotated using the traditional copy/truncate method. NOTE: You may or may not see stuff printed to stdout as stdout was traditionally used by CGI applications to communicate with the webserver. Closes: <https://github.com/nginx/unit/issues/197> Closes: <https://github.com/nginx/unit/issues/846> Reviewed-by: Alejandro Colomar <alx@nginx.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2023-04-11Add nxt_file_stdout().Andrew Clayton2-0/+20
This is analogous to the nxt_file_stderr() function and will be used in a subsequent commit. This function redirects stdout to a given file descriptor. Reviewed-by: Alejandro Colomar <alx@nginx.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>