summaryrefslogtreecommitdiffhomepage
path: root/src (follow)
AgeCommit message (Collapse)AuthorFilesLines
2023-02-23Win32: reworked ngx_win32_rename_file() to check errors.Maxim Dounin1-2/+10
Previously, ngx_win32_rename_file() retried on all errors returned by MoveFile() to a temporary name. It only make sense, however, to retry when the destination file already exists, similarly to the condition when ngx_win32_rename_file() is called. Retrying on other errors is meaningless and might result in an infinite loop.
2023-02-23Win32: non-ASCII directory names support in ngx_delete_dir().Maxim Dounin2-1/+37
This makes it possible to delete directories with non-ASCII characters when using the dav module (ticket #1433).
2023-02-23Win32: non-ASCII directory names support in ngx_create_dir().Maxim Dounin2-10/+72
This makes it possible to create directories under prefix with non-ASCII characters, as well as makes it possible to create directories with non-ASCII characters when using the dav module (ticket #1433). To ensure that the dav module operations are restricted similarly to other file operations (in particular, short names are not allowed), the ngx_win32_check_filename() function is used. It improved to support checking of just dirname, and now can be used to check paths when creating files or directories.
2023-02-23Win32: non-ASCII directory names support in ngx_getcwd().Maxim Dounin2-1/+39
This makes it possible to start nginx without a prefix explicitly set in a directory with non-ASCII characters in it.
2023-02-23Win32: non-ASCII names support in "include" with wildcards.Maxim Dounin2-34/+64
Notably, ngx_open_glob() now supports opening directories with non-ASCII characters, and pathnames returned by ngx_read_glob() are converted to UTF-8.
2023-02-23Win32: non-ASCII names support in autoindex (ticket #458).Maxim Dounin2-21/+244
Notably, ngx_open_dir() now supports opening directories with non-ASCII characters, and directory entries returned by ngx_read_dir() are properly converted to UTF-8.
2023-02-02Lingering close for connections with pipelined requests.Maxim Dounin2-1/+4
This is expected to help with clients using pipelining with some constant depth, such as apt[1][2]. When downloading many resources, apt uses pipelining with some constant depth, a number of requests in flight. This essentially means that after receiving a response it sends an additional request to the server, and this can result in requests arriving to the server at any time. Further, additional requests are sent one-by-one, and can be easily seen as such (neither as pipelined, nor followed by pipelined requests). The only safe approach to close such connections (for example, when keepalive_requests is reached) is with lingering. To do so, now nginx monitors if pipelining was used on the connection, and if it was, closes the connection with lingering. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973861#10 [2] https://mailman.nginx.org/pipermail/nginx-devel/2023-January/ZA2SP5SJU55LHEBCJMFDB2AZVELRLTHI.html
2023-01-28Fixed "zero size buf" alerts with subrequests.Maxim Dounin6-12/+6
Since 4611:2b6cb7528409 responses from the gzip static, flv, and mp4 modules can be used with subrequests, though empty files were not properly handled. Empty gzipped, flv, and mp4 files thus resulted in "zero size buf in output" alerts. While valid corresponding files are not expected to be empty, such files shouldn't result in alerts. Fix is to set b->sync on such empty subrequest responses, similarly to what ngx_http_send_special() does. Additionally, the static module, the ngx_http_send_response() function, and file cache are modified to do the same instead of not sending the response body at all in such cases, since not sending the response body at all is believed to be at least questionable, and might break various filters which do not expect such behaviour.
2023-01-28Style.Maxim Dounin4-7/+7
2023-01-28Added warning about redefinition of listen socket protocol options.Maxim Dounin2-1/+66
The "listen" directive in the http module can be used multiple times in different server blocks. Originally, it was supposed to be specified once with various socket options, and without any parameters in virtual server blocks. For example: server { listen 80 backlog=1024; server_name foo; ... } server { listen 80; server_name bar; ... } server { listen 80; server_name bazz; ... } The address part of the syntax ("address[:port]" / "port" / "unix:path") uniquely identifies the listening socket, and therefore is enough for name-based virtual servers (to let nginx know that the virtual server accepts requests on the listening socket in question). To ensure that listening options do not conflict between virtual servers, they were allowed only once. For example, the following configuration will be rejected ("duplicate listen options for 0.0.0.0:80 in ..."): server { listen 80 backlog=1024; server_name foo; ... } server { listen 80 backlog=512; server_name bar; ... } At some point it was, however, noticed, that it is sometimes convenient to repeat some options for clarity. In nginx 0.8.51 the "ssl" parameter was allowed to be specified multiple times, e.g.: server { listen 443 ssl backlog=1024; server_name foo; ... } server { listen 443 ssl; server_name bar; ... } server { listen 443 ssl; server_name bazz; ... } This approach makes configuration more readable, since SSL sockets are immediately visible in the configuration. If this is not needed, just the address can still be used. Later, additional protocol-specific options similar to "ssl" were introduced, notably "http2" and "proxy_protocol". With these options, one can write: server { listen 443 ssl backlog=1024; server_name foo; ... } server { listen 443 http2; server_name bar; ... } server { listen 443 proxy_protocol; server_name bazz; ... } The resulting socket will use ssl, http2, and proxy_protocol, but this is not really obvious from the configuration. To emphasize such misleading configurations are discouraged, nginx now warns as long as the "listen" directive is used with options different from the options previously used if this is potentially confusing. In particular, the following configurations are allowed: server { listen 8401 ssl backlog=1024; server_name foo; } server { listen 8401 ssl; server_name bar; } server { listen 8401 ssl; server_name bazz; } server { listen 8402 ssl http2 backlog=1024; server_name foo; } server { listen 8402 ssl; server_name bar; } server { listen 8402 ssl; server_name bazz; } server { listen 8403 ssl; server_name bar; } server { listen 8403 ssl; server_name bazz; } server { listen 8403 ssl http2; server_name foo; } server { listen 8404 ssl http2 backlog=1024; server_name foo; } server { listen 8404 http2; server_name bar; } server { listen 8404 http2; server_name bazz; } server { listen 8405 ssl http2 backlog=1024; server_name foo; } server { listen 8405 ssl http2; server_name bar; } server { listen 8405 ssl http2; server_name bazz; } server { listen 8406 ssl; server_name foo; } server { listen 8406; server_name bar; } server { listen 8406; server_name bazz; } And the following configurations will generate warnings: server { listen 8501 ssl http2 backlog=1024; server_name foo; } server { listen 8501 http2; server_name bar; } server { listen 8501 ssl; server_name bazz; } server { listen 8502 backlog=1024; server_name foo; } server { listen 8502 ssl; server_name bar; } server { listen 8503 ssl; server_name foo; } server { listen 8503 http2; server_name bar; } server { listen 8504 ssl; server_name foo; } server { listen 8504 http2; server_name bar; } server { listen 8504 proxy_protocol; server_name bazz; } server { listen 8505 ssl http2 proxy_protocol; server_name foo; } server { listen 8505 ssl http2; server_name bar; } server { listen 8505 ssl; server_name bazz; } server { listen 8506 ssl http2; server_name foo; } server { listen 8506 ssl; server_name bar; } server { listen 8506; server_name bazz; } server { listen 8507 ssl; server_name bar; } server { listen 8507; server_name bazz; } server { listen 8507 ssl http2; server_name foo; } server { listen 8508 ssl; server_name bar; } server { listen 8508; server_name bazz; } server { listen 8508 ssl backlog=1024; server_name foo; } server { listen 8509; server_name bazz; } server { listen 8509 ssl; server_name bar; } server { listen 8509 ssl backlog=1024; server_name foo; } The basic idea is that at most two sets of protocol options are allowed: the main one (with socket options, if any), and a shorter one, with options being a subset of the main options, repeated for clarity. As long as the shorter set of protocol options is used, all listen directives except the main one should use it.
2023-01-26HTTP/3: trigger more compatibility errors for "listen quic".Roman Arutyunyan1-3/+19
Now "ssl", "proxy_protocol" and "http2" are not allowed with "quic" in "listen" directive. Previously, only "ssl" was not allowed.
2023-02-27HTTP/3: "quic" parameter of "listen" directive.Roman Arutyunyan10-85/+121
Now "listen" directve has a new "quic" parameter which enables QUIC protocol for the address. Further, to enable HTTP/3, a new directive "http3" is introduced. The hq-interop protocol is enabled by "http3_hq" as before. Now application protocol is chosen by ALPN. Previously used "http3" parameter of "listen" is deprecated.
2023-02-22QUIC: OpenSSL compatibility layer.Roman Arutyunyan8-49/+789
The change allows to compile QUIC with OpenSSL which lacks BoringSSL QUIC API. This implementation does not support 0-RTT.
2023-02-23QUIC: improved ssl_reject_handshake error logging.Sergey Kandaurov1-0/+8
The check follows the ngx_ssl_handshake() change in 59e1c73fe02b.
2023-02-23QUIC: using ngx_ssl_handshake_log().Sergey Kandaurov3-9/+7
2023-02-23QUIC: moved "handshake failed" reason to send_alert.Sergey Kandaurov1-1/+1
A QUIC handshake failure breaks down into several cases: - a handshake error which leads to a send_alert call - an error triggered by the add_handshake_data callback - internal errors (allocation etc) Previously, in the first case, only error code was set in the send_alert callback. Now the "handshake failed" reason phrase is set there as well. In the second case, both code and reason are set by add_handshake_data. In the last case, setting reason phrase is removed: returning NGX_ERROR now leads to closing the connection with just INTERNAL_ERROR. Reported by Jiuzhou Cui.
2023-02-23QUIC: using NGX_QUIC_ERR_CRYPTO macro in ALPN checks.Sergey Kandaurov1-1/+1
Patch by Jiuzhou Cui.
2023-02-13QUIC: fixed indentation.Sergey Kandaurov2-3/+3
2023-01-31QUIC: fixed broken token in NEW_TOKEN (ticket #2446).Roman Arutyunyan4-8/+34
Previously, since 3550b00d9dc8, the token was allocated on stack, to get rid of pool usage. Now the token is allocated by ngx_quic_copy_buffer() in QUIC buffers, also used for STREAM, CRYPTO and ACK frames.
2023-01-31QUIC: ngx_quic_copy_buffer() function.Roman Arutyunyan3-21/+37
The function copies passed data to QUIC buffer chain and returns it. The chain can be used in ngx_quic_frame_t data field.
2023-01-26Fixed handling of very long locations (ticket #2435).Maxim Dounin2-2/+2
Previously, location prefix length in ngx_http_location_tree_node_t was stored as "u_char", and therefore location prefixes longer than 255 bytes were handled incorrectly. Fix is to use "u_short" instead. With "u_short", prefixes up to 65535 bytes can be safely used, and this isn't reachable due to NGX_CONF_BUFFER, which is 4096 bytes.
2023-01-24Gzip static: ranges support (ticket #2349).Maxim Dounin1-0/+2
In contrast to on-the-fly gzipping with gzip filter, static gzipped representation as returned by gzip_static is persistent, and therefore the same binary representation is available for future requests, making it possible to use range requests. Further, if a gzipped representation is re-generated with different compression settings, it is expected to result in different ETag and different size reported in the Content-Range header, making it possible to safely use range requests anyway. As such, ranges are now allowed for files returned by gzip_static.
2023-01-18QUIC: defer setting the active flag for client stream events.Sergey Kandaurov1-18/+21
Specifically, now it is kept unset until streams are initialized. Notably, this unbreaks OCSP with client certificates after 35e27117b593. Previously, the read event could be posted prematurely via ngx_quic_set_event() e.g., as part of handling a STREAM frame.
2023-01-10QUIC: relocated ngx_quic_init_streams() for 0-RTT.Roman Arutyunyan1-13/+9
Previously, streams were initialized in early keys handler. However, client transport parameters may not be available by then. This happens, for example, when using QuicTLS. Now streams are initialized in ngx_quic_crypto_input() after calling SSL_do_handshake() for both 0-RTT and 1-RTT.
2023-01-05HTTP/3: insert count block timeout.Roman Arutyunyan1-0/+6
Previously, there was no timeout for a request stream blocked on insert count, which could result in infinite wait. Now client_header_timeout is set when stream is first blocked.
2023-01-05HTTP/3: trigger 400 (Bad Request) on stream error while blocked.Roman Arutyunyan1-1/+1
Previously, stream was closed with NGX_HTTP_CLOSE. However, in a similar case when recv() returns eof or error, status 400 is triggered.
2023-01-10QUIC: set stream error flag on reset.Roman Arutyunyan1-2/+12
Now, when RESET_STREAM is sent or received, or when streams are closed, stream connection error flag is set. Previously, only stream state was changed, which resulted in setting the error flag only after calling recv()/send()/send_chain(). However, there are cases when none of these functions is called, but it's still important to know if the stream is being closed. For example, when an HTTP/3 request stream is blocked on insert count, receiving RESET_STREAM should trigger stream closure, which was not the case. The change also fixes ngx_http_upstream_check_broken_connection() and ngx_http_test_reading() with QUIC streams.
2023-01-10QUIC: automatically add and never delete stream events.Roman Arutyunyan3-32/+9
Previously, stream events were added and deleted by ngx_handle_read_event() and ngx_handle_write_event() in a way similar to level-triggered events. However, QUIC stream events are effectively edge-triggered and can stay active all time. Moreover, the events are now active since the moment a stream is created.
2023-01-10HTTP/3: fixed $connection_time.Sergey Kandaurov2-4/+2
Previously, start_time wasn't set for a new stream. The fix is to derive it from the parent connection. Also it's used to simplify tracking keepalive_time.
2023-01-03HTTP/3: handled insertion reference to a going to be evicted entry.Roman Arutyunyan1-21/+16
As per RFC 9204, section 3.2.2, a new entry can reference an entry in the dynamic table that will be evicted when adding this new entry into the dynamic table. Previously, such inserts resulted in use-after-free since the old entry was evicted before the insertion (ticket #2431). Now it's evicted after the insertion. This change fixes Insert with Name Reference and Duplicate encoder instructions.
2023-01-02Merged with the default branch.Sergey Kandaurov9-11/+11
2022-12-21Updated link to OpenVZ suspend/resume bug.Maxim Dounin1-1/+1
2022-12-18Fixed port ranges support in the listen directive.Valentin Bartenev3-3/+3
Ports difference must be respected when checking addresses for duplicates, otherwise configurations like this are broken: listen 127.0.0.1:6000-6005 It was broken by 4cc2bfeff46c (nginx 1.23.3).
2022-12-16Style.BullerDu3-4/+4
2022-12-16Version bump.Sergey Kandaurov1-2/+2
2022-12-15Merged with the default branch.Sergey Kandaurov17-61/+158
2022-12-01Win32: event flags handling edge cases in ngx_wsarecv().Maxim Dounin2-0/+4
Fixed event flags handling edge cases in ngx_wsarecv() and ngx_wsarecv_chain(), notably to always reset rev->ready in case of errors (which wasn't the case after ngx_socket_nread() errors), and after EOF (rev->ready was not cleared if due to a misconfiguration a zero-sized buffer was used for reading).
2022-12-01SSL: fixed ngx_ssl_recv() to reset c->read->ready after errors.Maxim Dounin2-3/+7
With this change, behaviour of ngx_ssl_recv() now matches ngx_unix_recv(), which used to always reset c->read->ready to 0 when returning errors. This fixes an infinite loop in unbuffered SSL proxying if writing to the client is blocked and an SSL error happens (ticket #2418). With this change, the fix for a similar issue in the stream module (6868:ee3645078759), which used a different approach of explicitly testing c->read->error instead, is no longer needed and was reverted.
2022-11-30Removed casts from ngx_memcmp() macro.Maxim Dounin1-1/+1
Casts are believed to be not needed, since memcmp() has "const void *" arguments since introduction of the "void" type in C89. And on pre-C89 platforms nginx is unlikely to compile without warnings anyway, as there are no casts in memcpy() and memmove() calls. These casts were added in 1648:89a47f19b9ec without any details on why they were added, and Igor does not remember details either. The most plausible explanation is that they were copied from ngx_strcmp() and were not really needed even at that time. Prodded by Alejandro Colomar.
2022-11-30Fixed alignment of ngx_memmove()/ngx_movemem() macro definitions.Maxim Dounin1-2/+2
2022-11-24SSL: fixed debug logging of SSL_sendfile() return value.Sergey Kandaurov1-1/+1
2022-11-23Fixed segfault when switching off master process during upgrade.Maxim Dounin2-11/+3
Binary upgrades are not supported without master process, but it is, however, possible, that nginx running with master process is asked to upgrade binary, and the configuration file as available on disk at this time includes "master_process off;". If this happens, listening sockets inherited from the previous binary will have ls[i].previous set. But the old cycle on initial process startup, including startup after binary upgrade, is destroyed by ngx_init_cycle() once configuration parsing is complete. As a result, an attempt to dereference ls[i].previous in ngx_event_process_init() accesses already freed memory. Fix is to avoid looking into ls[i].previous if the old cycle is already freed. With this change it is also no longer needed to clear ls[i].previous in worker processes, so the relevant code was removed.
2022-11-23Disabled cloning of sockets without master process (ticket #2403).Maxim Dounin1-1/+4
Cloning of listening sockets for each worker process does not make sense when working without master process, and causes some of the connections not to be accepted if worker_processes is set to more than one and there are listening sockets configured with the reuseport flag. Fix is to disable cloning when master process is disabled.
2022-11-23Filtering duplicate addresses in listen (ticket #2400).Maxim Dounin3-26/+85
Due to the glibc bug[1], getaddrinfo("localhost") with AI_ADDRCONFIG on a typical host with glibc and without IPv6 returns two 127.0.0.1 addresses, and therefore "listen localhost:80;" used to result in "duplicate ... address and port pair" after 4f9b72a229c1. Fix is to explicitly filter out duplicate addresses returned during resolution of a name. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=14969
2022-11-18Process events posted by ngx_close_idle_connections() immediately.Roman Arutyunyan2-0/+2
Previously, if an event was posted by a read event handler, called by ngx_close_idle_connections(), that event was not processed until the next event loop iteration, which could happen after a timeout.
2022-11-21SSI: handling of subrequests from other modules (ticket #1263).Ciel Zhao2-1/+29
As the SSI parser always uses the context from the main request for storing variables and blocks, that context should always exist for subrequests using SSI, even though the main request does not necessarily have SSI enabled. However, `ngx_http_get_module_ctx(r->main, ...)` is getting NULL in such cases, resulting in the worker crashing SIGSEGV when accessing its attributes. This patch links the first initialized context to the main request, and upgrades it only when main context is initialized.
2022-11-08Fixed PROXY protocol to use ngx_memcpy()/ngx_memcmp().Maxim Dounin1-5/+5
2022-11-08Added logging to PROXY protocol write buffer check.Maxim Dounin1-0/+2
The check is not expected to fail unless there is a bug in the calling code. But given the check is here, it should log an alert if it fails instead of silently closing the connection.
2022-11-02Increased maximum read PROXY protocol header size.Roman Arutyunyan4-8/+11
Maximum size for reading the PROXY protocol header is increased to 4096 to accommodate a bigger number of TLVs, which are supported since cca4c8a715de. Maximum size for writing the PROXY protocol header is not changed since only version 1 is currently supported.
2022-11-03Version bump.Roman Arutyunyan1-2/+2