summaryrefslogtreecommitdiff
path: root/src/http/modules
Commit message (Collapse)AuthorAgeFilesLines
* Gzip: compatibility with recent zlib-ng versions.Maxim Dounin2023-03-271-6/+12
| | | | | | | | | | | | It now uses custom alloc_aligned() wrapper for all allocations, therefore all allocations are larger than expected by (64 + sizeof(void*)). Further, they are seen as allocations of 1 element. Relevant calculations were adjusted to reflect this, and state allocation is now protected with a flag to avoid misinterpreting other allocations as the zlib deflate_state allocation. Further, it no longer forces window bits to 13 on compression level 1, so the comment was adjusted to reflect this.
* SSL: enabled TLSv1.3 by default.Maxim Dounin2023-03-244-8/+12
|
* Fixed "zero size buf" alerts with subrequests.Maxim Dounin2023-01-284-4/+4
| | | | | | | | | | | | | | | | | 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.
* Style.Maxim Dounin2023-01-282-3/+3
|
* Gzip static: ranges support (ticket #2349).Maxim Dounin2023-01-241-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.
* SSI: handling of subrequests from other modules (ticket #1263).Ciel Zhao2022-11-212-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.
* Mp4: disabled duplicate atoms.Roman Arutyunyan2022-10-191-0/+147
| | | | | | Most atoms should not appear more than once in a container. Previously, this was not enforced by the module, which could result in worker process crash, memory corruption and disclosure.
* SSL: improved validation of ssl_session_cache and ssl_ocsp_cache.Sergey Kandaurov2022-10-171-2/+2
| | | | | | | Now it properly detects invalid shared zone configuration with omitted size. Previously it used to read outside of the buffer boundary. Found with AddressSanitizer.
* Range filter: clearing of pre-existing Content-Range headers.Maxim Dounin2022-07-151-0/+13
| | | | | | | | Some servers might emit Content-Range header on 200 responses, and this does not seem to contradict RFC 9110: as per RFC 9110, the Content-Range header has no meaning for status codes other than 206 and 416. Previously this resulted in duplicate Content-Range headers in nginx responses handled by the range filter. Fix is to clear pre-existing headers.
* Upstream: optimized use of SSL contexts (ticket #1234).Maxim Dounin2022-06-293-21/+177
| | | | | | | | | | | | To ensure optimal use of memory, SSL contexts for proxying are now inherited from previous levels as long as relevant proxy_ssl_* directives are not redefined. Further, when no proxy_ssl_* directives are redefined in a server block, we now preserve plcf->upstream.ssl in the "http" section configuration to inherit it to all servers. Similar changes made in uwsgi, grpc, and stream proxy.
* Perl: removed unused variables, forgotten in ef6a3a99a81a.Sergey Kandaurov2022-06-141-2/+1
|
* Mp4: fixed potential overflow in ngx_http_mp4_crop_stts_data().Maxim Dounin2022-06-071-1/+1
| | | | | | | | Both "count" and "duration" variables are 32-bit, so their product might potentially overflow. It is used to reduce 64-bit start_time variable, and with very large start_time this can result in incorrect seeking. Found by Coverity (CID 1499904).
* Upstream: handling of certificates specified as an empty string.Sergey Kandaurov2022-06-073-6/+9
| | | | | | | Now, if the directive is given an empty string, such configuration cancels loading of certificates, in particular, if they would be otherwise inherited from the previous level. This restores previous behaviour, before variables support in certificates was introduced (3ab8e1e2f0f7).
* Headers filter: improved memory allocation error handling.Maxim Dounin2022-05-301-0/+4
|
* Auth request: multiple WWW-Authenticate headers (ticket #485).Maxim Dounin2022-05-301-3/+8
| | | | | | When using auth_request with an upstream server which returns 401 (Unauthorized), multiple WWW-Authenticate headers from the upstream server response are now properly copied to the response.
* Upstream: header handlers can now return parsing errors.Maxim Dounin2022-05-305-10/+30
| | | | | | | With this change, duplicate Content-Length and Transfer-Encoding headers are now rejected. Further, responses with invalid Content-Length or Transfer-Encoding headers are now rejected, as well as responses with both Content-Length and Transfer-Encoding.
* Upstream: all known headers in u->headers_in are linked lists now.Maxim Dounin2022-05-301-0/+2
|
* All known output headers can be linked lists now.Maxim Dounin2022-05-3010-0/+13
| | | | | | | | The h->next pointer properly provided as NULL in all cases where known output headers are added. Note that there are 3rd party modules which might not do this, and it might be risky to rely on this for arbitrary headers.
* Perl: combining unknown headers during $r->header_in() lookup.Maxim Dounin2022-05-301-40/+44
|
* Perl: all known input headers are handled identically.Maxim Dounin2022-05-301-20/+2
| | | | | | | As all known input headers are now linked lists, these are now handled identically. In particular, this makes it possible to access properly combined values of headers not specifically handled previously, such as "Via" or "Connection".
* Reworked multi headers to use linked lists.Maxim Dounin2022-05-307-82/+51
| | | | | | | | | | | | | | | | | Multi headers are now using linked lists instead of arrays. Notably, the following fields were changed: r->headers_in.cookies (renamed to r->headers_in.cookie), r->headers_in.x_forwarded_for, r->headers_out.cache_control, r->headers_out.link, u->headers_in.cache_control u->headers_in.cookies (renamed to u->headers_in.set_cookie). The r->headers_in.cookies and u->headers_in.cookies fields were renamed to r->headers_in.cookie and u->headers_in.set_cookie to match header names. The ngx_http_parse_multi_header_lines() and ngx_http_parse_set_cookie_lines() functions were changed accordingly. With this change, multi headers are now essentially equivalent to normal headers, and following changes will further make them equivalent.
* Uwsgi: combining headers with identical names (ticket #1724).Maxim Dounin2022-05-301-6/+51
| | | | | | | | | | | The uwsgi specification states that "The uwsgi block vars represent a dictionary/hash". This implies that no duplicate headers are expected. Further, provided headers are expected to follow CGI specification, which also requires to combine headers (RFC 3875, section "4.1.18. Protocol-Specific Meta-Variables"): "If multiple header fields with the same field-name are received then the server MUST rewrite them as a single value having the same semantics".
* SCGI: combining headers with identical names (ticket #1724).Maxim Dounin2022-05-301-5/+45
| | | | | | | | | | | | SCGI specification explicitly forbids headers with duplicate names (section "3. Request Format"): "Duplicate names are not allowed in the headers". Further, provided headers are expected to follow CGI specification, which also requires to combine headers (RFC 3875, section "4.1.18. Protocol-Specific Meta-Variables"): "If multiple header fields with the same field-name are received then the server MUST rewrite them as a single value having the same semantics".
* FastCGI: combining headers with identical names (ticket #1724).Maxim Dounin2022-05-301-11/+55
| | | | | | | | | | | | FastCGI responder is expected to receive CGI/1.1 environment variables in the parameters (see section "6.2 Responder" of the FastCGI specification). Obviously enough, there cannot be multiple environment variables with the same name. Further, CGI specification (RFC 3875, section "4.1.18. Protocol-Specific Meta-Variables") explicitly requires to combine headers: "If multiple header fields with the same field-name are received then the server MUST rewrite them as a single value having the same semantics".
* Moved Huffman coding out of HTTP/2.Ruslan Ermilov2021-12-211-8/+8
| | | | | ngx_http_v2_huff_decode.c and ngx_http_v2_huff_encode.c are renamed to ngx_http_huff_decode.c and ngx_http_huff_encode.c.
* SSL: $ssl_curve (ticket #2135).Sergey Kandaurov2021-11-011-0/+3
| | | | | | | | | | | | | | | The variable contains a negotiated curve used for the handshake key exchange process. Known curves are listed by their names, unknown ones are shown in hex. Note that for resumed sessions in TLSv1.2 and older protocols, $ssl_curve contains the curve used during the initial handshake, while in TLSv1.3 it contains the curve used during the session resumption (see the SSL_get_negotiated_group manual page for details). The variable is only meaningful when using OpenSSL 3.0 and above. With older versions the variable is empty.
* Mp4: mp4_start_key_frame directive.Roman Arutyunyan2021-10-281-27/+194
| | | | | | | | | | | | | | The directive enables including all frames from start time to the most recent key frame in the result. Those frames are removed from presentation timeline using mp4 edit lists. Edit lists are currently supported by popular players and browsers such as Chrome, Safari, QuickTime and ffmpeg. Among those not supporting them properly is Firefox[1]. Based on a patch by Tracey Jaquith, Internet Archive. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1735300
* Mp4: added ngx_http_mp4_update_mdhd_atom() function.Roman Arutyunyan2021-10-281-8/+32
| | | | | | The function updates the duration field of mdhd atom. Previously it was updated in ngx_http_mp4_read_mdhd_atom(). The change makes it possible to alter track duration as a result of processing track frames.
* HTTP: connections with wrong ALPN protocols are now rejected.Vladimir Homutov2021-10-201-7/+6
| | | | | | | | | | | | This is a recommended behavior by RFC 7301 and is useful for mitigation of protocol confusion attacks [1]. To avoid possible negative effects, list of supported protocols was extended to include all possible HTTP protocol ALPN IDs registered by IANA [2], i.e. "http/1.0" and "http/0.9". [1] https://alpaca-attack.com/ [2] https://www.iana.org/assignments/tls-extensiontype-values/
* SSL: added $ssl_alpn_protocol variable.Vladimir Homutov2021-10-141-0/+3
| | | | | The variable contains protocol selected by ALPN during handshake and is empty otherwise.
* HTTP/2: removed support for NPN.Vladimir Homutov2021-10-151-54/+5
| | | | | | | | | | | | | | NPN was replaced with ALPN, published as RFC 7301 in July 2014. It used to negotiate SPDY (and, in transition, HTTP/2). NPN supported appeared in OpenSSL 1.0.1. It does not work with TLSv1.3 [1]. ALPN is supported since OpenSSL 1.0.2. The NPN support was dropped in Firefox 53 [2] and Chrome 51 [3]. [1] https://github.com/openssl/openssl/issues/3665. [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1248198 [3] https://www.chromestatus.com/feature/5767920709795840
* Upstream: fixed logging level of upstream invalid header errors.Maxim Dounin2021-10-184-4/+4
| | | | | | | In b87b7092cedb (nginx 1.21.1), logging level of "upstream sent invalid header" errors was accidentally changed to "info". This change restores the "error" level, which is a proper logging level for upstream-side errors.
* Proxy: disabled keepalive on extra data in non-buffered mode.Awdhesh Mathpal2021-10-071-0/+1
| | | | | | | The u->keepalive flag is initialized early if the response has no body (or an empty body), and needs to be reset if there are any extra data, similarly to how it is done in ngx_http_proxy_copy_filter(). Missed in 83c4622053b0.
* SSL: ciphers now set before loading certificates (ticket #2035).Maxim Dounin2021-08-164-25/+25
| | | | | | | To load old/weak server or client certificates it might be needed to adjust the security level, as introduced in OpenSSL 1.1.0. This change ensures that ciphers are set before loading the certificates, so security level changes via the cipher string apply to certificate loading.
* Improved logging of invalid headers.Maxim Dounin2021-06-284-12/+20
| | | | | | | | | | | | | | In 71edd9192f24 logging of invalid headers which were rejected with the NGX_HTTP_PARSE_INVALID_HEADER error was restricted to just the "client sent invalid header line" message, without any attempts to log the header itself. This patch returns logging of the header up to the invalid character and the character itself. The r->header_end pointer is now properly set in all cases to make logging possible. The same logging is also introduced when parsing headers from upstream servers.
* Disabled control characters and space in header names.Maxim Dounin2021-06-281-1/+1
| | | | | | | | | | | | | | Control characters (0x00-0x1f, 0x7f), space, and colon were never allowed in header names. The only somewhat valid use is header continuation which nginx never supported and which is explicitly obsolete by RFC 7230. Previously, such headers were considered invalid and were ignored by default (as per ignore_invalid_headers directive). With this change, such headers are unconditionally rejected. It is expected to make nginx more resilient to various attacks, in particular, with ignore_invalid_headers switched off (which is inherently unsecure, though nevertheless sometimes used in the wild).
* Disabled spaces in URIs (ticket #196).Maxim Dounin2021-06-281-2/+2
| | | | | | | From now on, requests with spaces in URIs are immediately rejected rather than allowed. Spaces were allowed in 31e9677b15a1 (0.8.41) to handle bad clients. It is believed that now this behaviour causes more harm than good.
* gRPC: RST_STREAM(NO_ERROR) handling micro-optimization.Sergey Kandaurov2021-06-171-0/+4
| | | | | After 2096b21fcd10, a single RST_STREAM(NO_ERROR) may not result in an error. This change removes several unnecessary ctx->type checks for such a case.
* gRPC: handling GOAWAY with a higher last stream identifier.Sergey Kandaurov2021-06-171-0/+9
| | | | | Previously, once received from upstream, it couldn't limit opening additional streams in a cached keepalive connection.
* Location header escaping in redirects (ticket #882).Ruslan Ermilov2021-05-242-4/+38
| | | | | The header is escaped in redirects based on request URI or location name (auto redirect).
* Upstream: variables support in certificates.Maxim Dounin2021-05-063-73/+111
|
* Auth basic: changed alcf->user_file to be a pointer.Maxim Dounin2021-05-061-9/+12
| | | | | This saves some memory in typical case when auth_basic_user_file is not explicitly set, and unifies the code with alcf->realm.
* Changed complex value slots to use NGX_CONF_UNSET_PTR.Maxim Dounin2021-05-065-32/+26
| | | | | | | | | | | With this change, it is now possible to use ngx_conf_merge_ptr_value() to merge complex values. This change follows much earlier changes in ngx_conf_merge_ptr_value() and ngx_conf_set_str_array_slot() in 1452:cd586e963db0 (0.6.10) and 1701:40d004d95d88 (0.6.22), and the change in ngx_conf_set_keyval_slot() (7728:485dba3e2a01, 1.19.4). To preserve compatibility with existing 3rd party modules, both NULL and NGX_CONF_UNSET_PTR are accepted for now.
* Changed keepalive_requests default to 1000 (ticket #2155).Maxim Dounin2021-04-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | It turns out no browsers implement HTTP/2 GOAWAY handling properly, and large enough number of resources on a page results in failures to load some resources. In particular, Chrome seems to experience errors if loading of all resources requires more than 1 connection (while it is usually able to retry requests at least once, even with 2 connections there are occasional failures for some reason), Safari if loading requires more than 3 connections, and Firefox if loading requires more than 10 connections (can be configured with network.http.request.max-attempts, defaults to 10). It does not seem to be possible to resolve this on nginx side, even strict limiting of maximum concurrency does not help, and loading issues seems to be triggered by merely queueing of a request for a particular connection. The only available mitigation seems to use higher keepalive_requests value. The new default is 1000 and matches previously used default for http2_max_requests. It is expected to be enough for 99.98% of the pages (https://httparchive.org/reports/state-of-the-web?start=latest#reqTotal) even in Chrome.
* Introduced the "keepalive_time" directive.Maxim Dounin2021-04-081-0/+14
| | | | | | | Similar to lingering_time, it limits total connection lifetime before keepalive is switched off. The default is 1 hour, which is close to the total maximum connection lifetime possible with default keepalive_requests and keepalive_timeout.
* Gzip: updated handling of zlib variant from Intel.Maxim Dounin2021-04-051-26/+9
| | | | | | | | In current versions (all versions based on zlib 1.2.11, at least since 2018) it no longer uses 64K hash and does not force window bits to 13 if it is less than 13. That is, it needs just 16 bytes more memory than normal zlib, so these bytes are simply added to the normal size calculation.
* Gzip: support for zlib-ng.Maxim Dounin2021-04-051-2/+21
|
* Fixed handling of already closed connections.Maxim Dounin2021-03-281-2/+7
| | | | | | | | | | | | In limit_req, auth_delay, and upstream code to check for broken connections, tests for possible connection close by the client did not work if the connection was already closed when relevant event handler was set. This happened because there were no additional events in case of edge-triggered event methods, and read events were disabled in case of level-triggered ones. Fix is to explicitly post a read event if the c->read->ready flag is set.
* gRPC: fixed handling of padding on DATA frames.Maxim Dounin2021-03-231-11/+24
| | | | | | | | | | | | | | The response size check introduced in 39501ce97e29 did not take into account possible padding on DATA frames, resulting in incorrect "upstream sent response body larger than indicated content length" errors if upstream server used padding in responses with known length. Fix is to check the actual size of response buffers produced by the code, similarly to how it is done in other protocols, instead of checking the size of DATA frames. Reported at: http://mailman.nginx.org/pipermail/nginx-devel/2021-March/013907.html
* SSL: fixed build by Sun C with old OpenSSL versions.Maxim Dounin2021-03-054-8/+8
| | | | | Sun C complains about "statement not reached" if a "return" is followed by additional statements.
View Lorry Controller Status