/unit/auto/ |
H A D | shmem | diff 461:4d7e73b40330 Thu Jan 11 14:13:00 UTC 2018 Igor Sysoev <igor@sysoev.ru> Fixed DragonFly BSD shared memory implementation.
|
H A D | make | diff 2439:4cabfc9895f4 Mon Apr 24 15:59:00 UTC 2023 Alejandro Colomar <alx@nginx.com> Docs: moved uintd.8 to man8/ subdirectory.
Reviewed-by: Artem Konev <a.konev@f5.com> Signed-off-by: Alejandro Colomar <alx@nginx.com> diff 2314:bc5a90e2e6e8 Thu Jul 14 11:25:00 UTC 2022 Alejandro Colomar <alx.manpages@gmail.com> Added default values for pathnames.
This allows one to simply run `./configure` and expect it to produce sane defaults for an install.
Previously, without specifying `--prefix=...`, `make install` would simply fail, recommending to set `--prefix` or `DESTDIR`, but that recommendation was incomplete at best, since it didn't set many of the subdirs needed for a good organization.
Setting `DESTDIR` was even worse, since that shouldn't even affect an installation (it is required to be transparent to the installation).
/usr/local is the historic Unix standard path to use for installations from source made manually by the admin of the system. Some package managers (Homebrew, I'm looking specifically at you) have abused that path to install their things, but 1) it's not our fault that someone else incorrectly abuses that path (and they seem to be fixing it for newer archs; e.g., they started using /opt/homebrew for Apple Silicon), 2) there's no better path than /usr/local, 3) we still allow changing it for systems where this might not be the desired path (MacOS Intel with hombrew), and 4) it's _the standard_.
See a related conversation with Ingo (OpenBSD maintainer):
On 7/27/22 16:16, Ingo Schwarze wrote: > Hi Alejandro, [...] > > Alejandro Colomar wrote on Sun, Jul 24, 2022 at 07:07:18PM +0200: >> On 7/24/22 16:57, Ingo Schwarze wrote: >>> Alejandro Colomar wrote on Sun, Jul 24, 2022 at 01:20:46PM +0200: > >>>> /usr/local is for sysadmins to build from source; > >>> Doing that is *very* strongly discouraged on OpenBSD. > >> I guess that's why the directory was reused in the BSDs to install ports >> (probably ports were installed by the sysadmin there, and by extension, >> ports are now always installed there, but that's just a guess). > > Maybe. In any case, the practice of using /usr/local for packages > created from ports is significantly older than the recommendation > to refrain from using upstream "make install" outside the ports > framework. > > * The FreeBSD ports framework was started by Jordan Hubbard in 1993. > * The ports framework was ported from FreeBSD to OpenBSD > by Niklas Hallqvist in 1996. > * NetBSD pkgsrc was forked from FreeBSD ports by Alistair G. Crooks > and Hubert Feyrer in 1997. > > I failed to quickly find Jordan's original version, but rev. 1.1 > of /usr/ports/infrastructure/mk/bsd.port.mk in OpenBSD (dated Jun 3 > 22:47:10 1996 UTC) already said > > LOCALBASE ?= /usr/local > PREFIX ?= ${LOCALBASE} > [...] >> I had a discussion in NGINX Unit about it, and >> the decission for now has been: "support prefix=/usr/local for default >> manual installation through the Makefile, and let BSD users adjust to >> their preferred path". > > That's an *excellent* solution for the task, thanks for doing it > the right way. By setting PREFIX=/usr/local by default in the > upstream Makefile, you are minimizing the work for *BSD porters. > > The BSD ports frameworks will typically run the upstreak "make install" > with the variable DESTDIR set to a custom value, for example > > DESTDIR=/usr/ports/pobj/groff-1.23.0/fake-amd64 > > so if the upstream Makefile sets PREFIX=/usr/local , > that's perfect, everything gets installed to the right place > without an intervention by the person doing the porting. > > Of course, if the upstream Makefile would use some other PREFIX, > that would not be a huge obstacle. All we have to do in that case > is pass the option --prefix=/usr/local to the ./configure script, > or something equivalent if the software isn't using GNU configure. > >> We were concerned that we might get collisions >> with the BSD port also installing in /usr/local, but that's the least >> evil (and considering BSD users don't typically run `make install`, it's >> not so bad). > > It's not bad at all. It's perfect. > > Of course, if a user wants to install *without* the ports framework, > they have to provide their own --prefix. But that's not an issue > because it is easy to do, and installing without a port is discouraged > anyway.
===
Directory variables should never contain a trailing slash (I've learned that the hard way, where some things would break unexpectedly). Especially, make(1) is likely to have problems when things have double slashes or a trailing slash, since it treats filenames as text strings. I've removed the trailing slash from the prefix, and added it to the derivate variables just after the prefix. pkg-config(1) also expects directory variables to have no trailing slash.
===
I also removed the code that would set variables as depending on the prefix if they didn't start with a slash, because that is a rather non-obvious behavior, and things should not always depend on prefix, but other dirs such as $(runstatedir), so if we keep a similar behavior it would be very unreliable. Better keep variables intact if set, or use the default if unset.
===
Print the real defaults for ./configure --help, rather than the actual values.
===
I used a subdirectory under the standard /var/lib for NXT_STATE, instead of a homemade "state" dir that does the same thing.
===
Modified the Makefile to create some dirs that weren't being created, and also remove those that weren't being removed in uninstall, probably because someone forgot to add them.
===
Add new options for setting the new variables, and rename some to be consistent with the standard names. Keep the old ones at configuration time for compatibility, but mark them as deprecated. Don't keep the old ones at exec time.
===
A summary of the default config is:
Unit configuration summary:
bin directory: ............. "/usr/local/bin" sbin directory: ............ "/usr/local/sbin" lib directory: ............. "/usr/local/lib" include directory: ......... "/usr/local/include" man pages directory: ....... "/usr/local/share/man" modules directory: ......... "/usr/local/lib/unit/modules" state directory: ........... "/usr/local/var/lib/unit" tmp directory: ............. "/tmp"
pid file: .................. "/usr/local/var/run/unit/unit.pid" log file: .................. "/usr/local/var/log/unit/unit.log"
control API socket: ........ "unix:/usr/local/var/run/unit/control.unit.sock"
Link: <https://www.gnu.org/prep/standards/html_node/Directory-Variables.html> Link: <https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html> Reviewed-by: Artem Konev <a.konev@f5.com> Reviewed-by: Andrew Clayton <a.clayton@nginx.com> Tested-by: Andrew Clayton <a.clayton@nginx.com> Reviewed-by: Konstantin Pavlov <thresh@nginx.com> Signed-off-by: Alejandro Colomar <alx@nginx.com> diff 395:4b85dc010702 Wed Nov 29 15:49:00 UTC 2017 Max Romanov <max.romanov@nginx.com> Using --ld-opt when linking modules. diff 331:4dc08d26205c Mon Sep 25 17:15:00 UTC 2017 Igor Sysoev <igor@sysoev.ru> Added state directory creation in install procedure. diff 20:4dc92b438f58 Thu Mar 09 15:03:00 UTC 2017 Igor Sysoev <igor@sysoev.ru> Processes refactoring. The cycle has been renamed to the runtime.
|
H A D | sources | diff 2175:e83cff38d672 Wed Aug 03 12:42:00 UTC 2022 Alejandro Colomar <alx.manpages@gmail.com> Removed dead code.
nxt_sockaddr_ntop() stopped being used in commit (git) 029942f4eb71. It has been replaced mostly by nxt_sockaddr_text().
commit 029942f4eb7196c2cff0d0e26bc6ff274138f7d8 Author: Igor Sysoev <igor@sysoev.ru> Date: Wed Feb 22 15:09:59 2017 +0300
I/O operations refactoring.
nxt_job_sockaddr_parse() stopped being used in commit (git) 794248090a74.
commit 794248090a74f31cbfcf24ea8c835df2d4d21073 Author: Igor Sysoev <igor@sysoev.ru> Date: Wed Mar 4 14:04:08 2020 +0300
Legacy upstream code removed.
Also, remove functions and types used only by those two functions:
nxt_job_sockaddr_unix_parse() nxt_job_sockaddr_inet6_parse() nxt_job_sockaddr_inet_parse() nxt_job_sockaddr_parse_t nxt_job_resolve() nxt_job_resolve_t diff 1975:6a47cab8f271 Tue Oct 26 12:43:00 UTC 2021 Valentin Bartenev <vbart@nginx.com> Custom implementation of Base64 decoding function.
Compared to the previous implementation based on OpenSSL, the new implementation has these advantages:
1. Strict and reliable detection of invalid strings, including strings with less than 4 bytes of garbage at the end;
2. Allows to use Base64 strings without '=' padding. diff 1489:4a3ec07f4b19 Thu May 28 13:57:00 UTC 2020 Tiago Natel de Moura <t.nateldemoura@f5.com> Added "rootfs" feature. diff 20:4dc92b438f58 Thu Mar 09 15:03:00 UTC 2017 Igor Sysoev <igor@sysoev.ru> Processes refactoring. The cycle has been renamed to the runtime. diff 4:76c63e9b6322 Fri Jan 27 08:35:00 UTC 2017 Igor Sysoev <igor@sysoev.ru> Work queues refactoring.
|
/unit/test/ |
H A D | test_php_isolation.py | diff 1848:4bd548074e2c Mon Apr 05 13:03:00 UTC 2021 Andrei Zeliankou <zelenkov@nginx.com> Tests: style.
|
H A D | test_njs.py | diff 2330:4b1f175f9c88 Tue Feb 21 17:21:00 UTC 2023 Andrei Zeliankou <zelenkov@nginx.com> Tests: switched to using f-strings.
Previously, it was necessary to support older versions of Python for compatibility. F-strings were released in Python 3.6. Python 3.5 was marked as unsupported by the end of 2020, so now it's possible to start using f-strings safely for better readability and performance.
|
H A D | test_python_targets.py | diff 2330:4b1f175f9c88 Tue Feb 21 17:21:00 UTC 2023 Andrei Zeliankou <zelenkov@nginx.com> Tests: switched to using f-strings.
Previously, it was necessary to support older versions of Python for compatibility. F-strings were released in Python 3.6. Python 3.5 was marked as unsupported by the end of 2020, so now it's possible to start using f-strings safely for better readability and performance.
|
H A D | test_client_ip.py | diff 2330:4b1f175f9c88 Tue Feb 21 17:21:00 UTC 2023 Andrei Zeliankou <zelenkov@nginx.com> Tests: switched to using f-strings.
Previously, it was necessary to support older versions of Python for compatibility. F-strings were released in Python 3.6. Python 3.5 was marked as unsupported by the end of 2020, so now it's possible to start using f-strings safely for better readability and performance.
|
H A D | test_static_chroot.py | diff 2330:4b1f175f9c88 Tue Feb 21 17:21:00 UTC 2023 Andrei Zeliankou <zelenkov@nginx.com> Tests: switched to using f-strings.
Previously, it was necessary to support older versions of Python for compatibility. F-strings were released in Python 3.6. Python 3.5 was marked as unsupported by the end of 2020, so now it's possible to start using f-strings safely for better readability and performance.
|
H A D | test_asgi_application.py | diff 2330:4b1f175f9c88 Tue Feb 21 17:21:00 UTC 2023 Andrei Zeliankou <zelenkov@nginx.com> Tests: switched to using f-strings.
Previously, it was necessary to support older versions of Python for compatibility. F-strings were released in Python 3.6. Python 3.5 was marked as unsupported by the end of 2020, so now it's possible to start using f-strings safely for better readability and performance. diff 1848:4bd548074e2c Mon Apr 05 13:03:00 UTC 2021 Andrei Zeliankou <zelenkov@nginx.com> Tests: style.
|
H A D | test_proxy_chunked.py | diff 2330:4b1f175f9c88 Tue Feb 21 17:21:00 UTC 2023 Andrei Zeliankou <zelenkov@nginx.com> Tests: switched to using f-strings.
Previously, it was necessary to support older versions of Python for compatibility. F-strings were released in Python 3.6. Python 3.5 was marked as unsupported by the end of 2020, so now it's possible to start using f-strings safely for better readability and performance.
|
H A D | test_asgi_targets.py | diff 2330:4b1f175f9c88 Tue Feb 21 17:21:00 UTC 2023 Andrei Zeliankou <zelenkov@nginx.com> Tests: switched to using f-strings.
Previously, it was necessary to support older versions of Python for compatibility. F-strings were released in Python 3.6. Python 3.5 was marked as unsupported by the end of 2020, so now it's possible to start using f-strings safely for better readability and performance.
|
H A D | test_reconfigure_tls.py | diff 2694:c11223916183 Wed Feb 07 16:23:00 UTC 2024 Andrei Zeliankou <zelenkov@nginx.com> Tests: skip some of TLS reconfiguration tests under AddressSanitizer
These tests cause router crash when run with AddressSanitizer:
================================================================= ==77196==ERROR: AddressSanitizer: heap-use-after-free on address 0x60c000079340 at pc 0x55d56b132d4b bp 0x7f8cc7f346b0 sp 0x7f8cc7f346a0 READ of size 1 at 0x60c000079340 thread T1 #0 0x55d56b132d4a in nxt_openssl_conn_io_shutdown src/nxt_openssl.c:1466 #1 0x55d56b0f6a25 in nxt_h1p_closing src/nxt_h1proto.c:2069 #2 0x55d56b1009a6 in nxt_h1p_shutdown src/nxt_h1proto.c:2038 #3 0x55d56b1014c3 in nxt_h1p_request_close src/nxt_h1proto.c:1718 #4 0x55d56b1045c0 in nxt_http_request_close_handler src/nxt_http_request.c:864 #5 0x55d56b104988 in nxt_http_request_done src/nxt_http_request.c:795 #6 0x55d56b0ba0c3 in nxt_event_engine_start src/nxt_event_engine.c:542 #7 0x55d56b0dcac2 in nxt_router_thread_start src/nxt_router.c:3645 #8 0x55d56b0b421b in nxt_thread_trampoline src/nxt_thread.c:126 #9 0x7f8ccab95ac2 (/lib/x86_64-linux-gnu/libc.so.6+0x94ac2) #10 0x7f8ccac2784f (/lib/x86_64-linux-gnu/libc.so.6+0x12684f)
|
H A D | test_tls.py | diff 2330:4b1f175f9c88 Tue Feb 21 17:21:00 UTC 2023 Andrei Zeliankou <zelenkov@nginx.com> Tests: switched to using f-strings.
Previously, it was necessary to support older versions of Python for compatibility. F-strings were released in Python 3.6. Python 3.5 was marked as unsupported by the end of 2020, so now it's possible to start using f-strings safely for better readability and performance. diff 1848:4bd548074e2c Mon Apr 05 13:03:00 UTC 2021 Andrei Zeliankou <zelenkov@nginx.com> Tests: style. diff 1775:4b4991514356 Thu Jan 14 03:04:00 UTC 2021 Andrei Zeliankou <zelenkov@nginx.com> Tests: added missing checks for configuration results.
|
H A D | test_python_environment.py | diff 2330:4b1f175f9c88 Tue Feb 21 17:21:00 UTC 2023 Andrei Zeliankou <zelenkov@nginx.com> Tests: switched to using f-strings.
Previously, it was necessary to support older versions of Python for compatibility. F-strings were released in Python 3.6. Python 3.5 was marked as unsupported by the end of 2020, so now it's possible to start using f-strings safely for better readability and performance.
|
/unit/src/ |
H A D | nxt_http_parse.h | diff 2430:50ce7e6977b6 Fri Mar 31 12:08:00 UTC 2023 Alejandro Colomar <alx@nginx.com> HTTP: optimizing $request_line.
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> diff 2430:50ce7e6977b6 Fri Mar 31 12:08:00 UTC 2023 Alejandro Colomar <alx@nginx.com> HTTP: optimizing $request_line.
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> diff 481:4bfbd8ce0e8a Mon Jan 15 17:50:00 UTC 2018 Valentin Bartenev <vbart@nginx.com> Improved HTTP version representation.
|
H A D | nxt_buf.c | diff 4:76c63e9b6322 Fri Jan 27 08:35:00 UTC 2017 Igor Sysoev <igor@sysoev.ru> Work queues refactoring.
|
H A D | nxt_signal.h | diff 20:4dc92b438f58 Thu Mar 09 15:03:00 UTC 2017 Igor Sysoev <igor@sysoev.ru> Processes refactoring. The cycle has been renamed to the runtime.
|
H A D | nxt_h1proto.c | diff 2430:50ce7e6977b6 Fri Mar 31 12:08:00 UTC 2023 Alejandro Colomar <alx@nginx.com> HTTP: optimizing $request_line.
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> diff 2430:50ce7e6977b6 Fri Mar 31 12:08:00 UTC 2023 Alejandro Colomar <alx@nginx.com> HTTP: optimizing $request_line.
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> diff 2078:0996dd223cdd Sat Dec 18 23:58:00 UTC 2021 Alejandro Colomar <alx.manpages@gmail.com> Fixed indentation.
Some lines (incorrectly) had an indentation of 3 or 5, or 7 or 9, or 11 or 13, or 15 or 17 spaces instead of 4, 8, 12, or 16. Fix them.
Found with:
$ find src -type f | xargs grep -n '^ [^ ]'; $ find src -type f | xargs grep -n '^ [^ *]'; $ find src -type f | xargs grep -n '^ [^ ]'; $ find src -type f | xargs grep -n '^ [^ *]'; $ find src -type f | xargs grep -n '^ [^ +]'; $ find src -type f | xargs grep -n '^ [^ *+]'; $ find src -type f | xargs grep -n '^ [^ +]'; $ find src -type f | xargs grep -n '^ [^ *+]'; diff 1235:4d5998f60f20 Thu Oct 10 16:42:00 UTC 2019 Igor Sysoev <igor@sysoev.ru> Style fixes. diff 1110:4ca6df50b4d4 Wed Jul 24 10:47:00 UTC 2019 Axel Duch <axel.duch@nginx.com> Added routing based on request scheme.
Scheme matches exact string “http” or “https”. diff 481:4bfbd8ce0e8a Mon Jan 15 17:50:00 UTC 2018 Valentin Bartenev <vbart@nginx.com> Improved HTTP version representation.
|
H A D | nxt_http.h | diff 2430:50ce7e6977b6 Fri Mar 31 12:08:00 UTC 2023 Alejandro Colomar <alx@nginx.com> HTTP: optimizing $request_line.
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> diff 2430:50ce7e6977b6 Fri Mar 31 12:08:00 UTC 2023 Alejandro Colomar <alx@nginx.com> HTTP: optimizing $request_line.
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> diff 2078:0996dd223cdd Sat Dec 18 23:58:00 UTC 2021 Alejandro Colomar <alx.manpages@gmail.com> Fixed indentation.
Some lines (incorrectly) had an indentation of 3 or 5, or 7 or 9, or 11 or 13, or 15 or 17 spaces instead of 4, 8, 12, or 16. Fix them.
Found with:
$ find src -type f | xargs grep -n '^ [^ ]'; $ find src -type f | xargs grep -n '^ [^ *]'; $ find src -type f | xargs grep -n '^ [^ ]'; $ find src -type f | xargs grep -n '^ [^ *]'; $ find src -type f | xargs grep -n '^ [^ +]'; $ find src -type f | xargs grep -n '^ [^ *+]'; $ find src -type f | xargs grep -n '^ [^ +]'; $ find src -type f | xargs grep -n '^ [^ *+]'; diff 1561:4dae2fd8e02a Wed Aug 12 12:25:00 UTC 2020 Max Romanov <max.romanov@nginx.com> Responding with error in case of first process start failure.
After shared application port introducing, request queue in router was removed and requests may stuck forever waiting for another process start. diff 1110:4ca6df50b4d4 Wed Jul 24 10:47:00 UTC 2019 Axel Duch <axel.duch@nginx.com> Added routing based on request scheme.
Scheme matches exact string “http” or “https”. diff 444:4bf1dca6173c Thu Dec 28 17:50:00 UTC 2017 Igor Sysoev <igor@sysoev.ru> Removed duplicate declaration.
|
H A D | nxt_array.h | diff 1489:4a3ec07f4b19 Thu May 28 13:57:00 UTC 2020 Tiago Natel de Moura <t.nateldemoura@f5.com> Added "rootfs" feature.
|
H A D | nxt_fiber.c | diff 4:76c63e9b6322 Fri Jan 27 08:35:00 UTC 2017 Igor Sysoev <igor@sysoev.ru> Work queues refactoring.
|
H A D | nxt_file.c | diff 20:4dc92b438f58 Thu Mar 09 15:03:00 UTC 2017 Igor Sysoev <igor@sysoev.ru> Processes refactoring. The cycle has been renamed to the runtime.
|
/unit/test/unit/applications/lang/ |
H A D | perl.py | diff 2330:4b1f175f9c88 Tue Feb 21 17:21:00 UTC 2023 Andrei Zeliankou <zelenkov@nginx.com> Tests: switched to using f-strings.
Previously, it was necessary to support older versions of Python for compatibility. F-strings were released in Python 3.6. Python 3.5 was marked as unsupported by the end of 2020, so now it's possible to start using f-strings safely for better readability and performance.
|
H A D | java.py | diff 2578:4abe14ad5581 Tue Oct 17 17:43:00 UTC 2023 Sergey A. Osokin <sergey.osokin@nginx.com> Update third-party components for the Java module. diff 2330:4b1f175f9c88 Tue Feb 21 17:21:00 UTC 2023 Andrei Zeliankou <zelenkov@nginx.com> Tests: switched to using f-strings.
Previously, it was necessary to support older versions of Python for compatibility. F-strings were released in Python 3.6. Python 3.5 was marked as unsupported by the end of 2020, so now it's possible to start using f-strings safely for better readability and performance.
|
/unit/auto/modules/ |
H A D | python | diff 2314:bc5a90e2e6e8 Thu Jul 14 11:25:00 UTC 2022 Alejandro Colomar <alx.manpages@gmail.com> Added default values for pathnames.
This allows one to simply run `./configure` and expect it to produce sane defaults for an install.
Previously, without specifying `--prefix=...`, `make install` would simply fail, recommending to set `--prefix` or `DESTDIR`, but that recommendation was incomplete at best, since it didn't set many of the subdirs needed for a good organization.
Setting `DESTDIR` was even worse, since that shouldn't even affect an installation (it is required to be transparent to the installation).
/usr/local is the historic Unix standard path to use for installations from source made manually by the admin of the system. Some package managers (Homebrew, I'm looking specifically at you) have abused that path to install their things, but 1) it's not our fault that someone else incorrectly abuses that path (and they seem to be fixing it for newer archs; e.g., they started using /opt/homebrew for Apple Silicon), 2) there's no better path than /usr/local, 3) we still allow changing it for systems where this might not be the desired path (MacOS Intel with hombrew), and 4) it's _the standard_.
See a related conversation with Ingo (OpenBSD maintainer):
On 7/27/22 16:16, Ingo Schwarze wrote: > Hi Alejandro, [...] > > Alejandro Colomar wrote on Sun, Jul 24, 2022 at 07:07:18PM +0200: >> On 7/24/22 16:57, Ingo Schwarze wrote: >>> Alejandro Colomar wrote on Sun, Jul 24, 2022 at 01:20:46PM +0200: > >>>> /usr/local is for sysadmins to build from source; > >>> Doing that is *very* strongly discouraged on OpenBSD. > >> I guess that's why the directory was reused in the BSDs to install ports >> (probably ports were installed by the sysadmin there, and by extension, >> ports are now always installed there, but that's just a guess). > > Maybe. In any case, the practice of using /usr/local for packages > created from ports is significantly older than the recommendation > to refrain from using upstream "make install" outside the ports > framework. > > * The FreeBSD ports framework was started by Jordan Hubbard in 1993. > * The ports framework was ported from FreeBSD to OpenBSD > by Niklas Hallqvist in 1996. > * NetBSD pkgsrc was forked from FreeBSD ports by Alistair G. Crooks > and Hubert Feyrer in 1997. > > I failed to quickly find Jordan's original version, but rev. 1.1 > of /usr/ports/infrastructure/mk/bsd.port.mk in OpenBSD (dated Jun 3 > 22:47:10 1996 UTC) already said > > LOCALBASE ?= /usr/local > PREFIX ?= ${LOCALBASE} > [...] >> I had a discussion in NGINX Unit about it, and >> the decission for now has been: "support prefix=/usr/local for default >> manual installation through the Makefile, and let BSD users adjust to >> their preferred path". > > That's an *excellent* solution for the task, thanks for doing it > the right way. By setting PREFIX=/usr/local by default in the > upstream Makefile, you are minimizing the work for *BSD porters. > > The BSD ports frameworks will typically run the upstreak "make install" > with the variable DESTDIR set to a custom value, for example > > DESTDIR=/usr/ports/pobj/groff-1.23.0/fake-amd64 > > so if the upstream Makefile sets PREFIX=/usr/local , > that's perfect, everything gets installed to the right place > without an intervention by the person doing the porting. > > Of course, if the upstream Makefile would use some other PREFIX, > that would not be a huge obstacle. All we have to do in that case > is pass the option --prefix=/usr/local to the ./configure script, > or something equivalent if the software isn't using GNU configure. > >> We were concerned that we might get collisions >> with the BSD port also installing in /usr/local, but that's the least >> evil (and considering BSD users don't typically run `make install`, it's >> not so bad). > > It's not bad at all. It's perfect. > > Of course, if a user wants to install *without* the ports framework, > they have to provide their own --prefix. But that's not an issue > because it is easy to do, and installing without a port is discouraged > anyway.
===
Directory variables should never contain a trailing slash (I've learned that the hard way, where some things would break unexpectedly). Especially, make(1) is likely to have problems when things have double slashes or a trailing slash, since it treats filenames as text strings. I've removed the trailing slash from the prefix, and added it to the derivate variables just after the prefix. pkg-config(1) also expects directory variables to have no trailing slash.
===
I also removed the code that would set variables as depending on the prefix if they didn't start with a slash, because that is a rather non-obvious behavior, and things should not always depend on prefix, but other dirs such as $(runstatedir), so if we keep a similar behavior it would be very unreliable. Better keep variables intact if set, or use the default if unset.
===
Print the real defaults for ./configure --help, rather than the actual values.
===
I used a subdirectory under the standard /var/lib for NXT_STATE, instead of a homemade "state" dir that does the same thing.
===
Modified the Makefile to create some dirs that weren't being created, and also remove those that weren't being removed in uninstall, probably because someone forgot to add them.
===
Add new options for setting the new variables, and rename some to be consistent with the standard names. Keep the old ones at configuration time for compatibility, but mark them as deprecated. Don't keep the old ones at exec time.
===
A summary of the default config is:
Unit configuration summary:
bin directory: ............. "/usr/local/bin" sbin directory: ............ "/usr/local/sbin" lib directory: ............. "/usr/local/lib" include directory: ......... "/usr/local/include" man pages directory: ....... "/usr/local/share/man" modules directory: ......... "/usr/local/lib/unit/modules" state directory: ........... "/usr/local/var/lib/unit" tmp directory: ............. "/tmp"
pid file: .................. "/usr/local/var/run/unit/unit.pid" log file: .................. "/usr/local/var/log/unit/unit.log"
control API socket: ........ "unix:/usr/local/var/run/unit/control.unit.sock"
Link: <https://www.gnu.org/prep/standards/html_node/Directory-Variables.html> Link: <https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html> Reviewed-by: Artem Konev <a.konev@f5.com> Reviewed-by: Andrew Clayton <a.clayton@nginx.com> Tested-by: Andrew Clayton <a.clayton@nginx.com> Reviewed-by: Konstantin Pavlov <thresh@nginx.com> Signed-off-by: Alejandro Colomar <alx@nginx.com> diff 1532:4b4d0c3ce94b Thu Jul 30 23:21:00 UTC 2020 Tiago Natel de Moura <t.nateldemoura@f5.com> Isolation: fixed the generation of mounts table.
Since the introduction of rootfs feature, some language modules can't be configured multiple times.
Now the configure generates a separate nxt_<module>_mounts.h for each module compiled. diff 1489:4a3ec07f4b19 Thu May 28 13:57:00 UTC 2020 Tiago Natel de Moura <t.nateldemoura@f5.com> Added "rootfs" feature. diff 395:4b85dc010702 Wed Nov 29 15:49:00 UTC 2017 Max Romanov <max.romanov@nginx.com> Using --ld-opt when linking modules.
|