From larry.martell at gmail.com Fri Jun 2 18:50:42 2023 From: larry.martell at gmail.com (Larry Martell) Date: Fri, 2 Jun 2023 14:50:42 -0400 Subject: Logging response body Message-ID: Is there a way to have nginx log the response body? -------------- next part -------------- An HTML attachment was scrubbed... URL: From community at thoughtmaybe.com Sat Jun 3 14:26:55 2023 From: community at thoughtmaybe.com (Jore) Date: Sun, 4 Jun 2023 00:26:55 +1000 Subject: Regex match the middle of a URL and also the ending? Message-ID: <41af9ed5-9b7c-ea96-9b47-6658731be92a@thoughtmaybe.com> Hi all, I have an app on a domain that is set by a developer to proxy at certain URLs: |example.com/browser/123foo0/stuff.js | for example, where |123foo0| is some random key. The key may also change length in future. That’s all fine. But I’d like to interrupt specific requests and not proxy them: I don’t want to serve anything after the key that is in the path |/welcome| for example, i.e. not proxy any of these: |example.com/browser/123foo0/welcome/welcome.html example.com/browser/foo456b/welcome/welcome.css example.com/browser/bar123f/welcome/welcome.js example.com/browser/456foob/welcome/other.stuff example.com/browser/foo789b/welcome/ | So I tried simple stuff first like: |location ^~ /browser/.*/welcome/welcome.html {...| but couldn’t even get that working, before moving on to try capturing groups like css files and scripts and so on. I also tried putting regex in quotes, but that didn’t seem to work either. What am I doing wrong? Here’s a truncated version of the conf, with the location blocks only: |location ^~ "/browser/.*/welcome/welcome.html" { return 200 'Not proxied.\n'; add_header Content-Type text/plain; } location ^~ /browser { proxy_pass http://127.0.0.1:1234; proxy_set_header Host $http_host; } # landing page location / { root /var/www/foobar; index index.html; try_files $uri $uri/ /index.html; } | Thanks, Jore ​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Sat Jun 3 17:16:07 2023 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sat, 3 Jun 2023 20:16:07 +0300 Subject: Regex match the middle of a URL and also the ending? In-Reply-To: <41af9ed5-9b7c-ea96-9b47-6658731be92a@thoughtmaybe.com> References: <41af9ed5-9b7c-ea96-9b47-6658731be92a@thoughtmaybe.com> Message-ID: Hello! On Sun, Jun 04, 2023 at 12:26:55AM +1000, Jore wrote: > Hi all, > > I have an app on a domain that is set by a developer to proxy at certain > URLs: > > |example.com/browser/123foo0/stuff.js | > > for example, where |123foo0| is some random key. The key may also change > length in future. > > That’s all fine. > > But I’d like to interrupt specific requests and not proxy them: I don’t > want to serve anything after the key that is in the path |/welcome| for > example, i.e. not proxy any of these: > > |example.com/browser/123foo0/welcome/welcome.html > example.com/browser/foo456b/welcome/welcome.css > example.com/browser/bar123f/welcome/welcome.js > example.com/browser/456foob/welcome/other.stuff > example.com/browser/foo789b/welcome/ | > > So I tried simple stuff first like: |location ^~ > /browser/.*/welcome/welcome.html {...| > but couldn’t even get that working, before moving on to try capturing > groups like css files and scripts and so on. > > I also tried putting regex in quotes, but that didn’t seem to work either. > > What am I doing wrong? > > Here’s a truncated version of the conf, with the location blocks only: > > |location ^~ "/browser/.*/welcome/welcome.html" { return 200 'Not > proxied.\n'; add_header Content-Type text/plain; } location ^~ /browser > { proxy_pass http://127.0.0.1:1234; proxy_set_header Host $http_host; } > # landing page location / { root /var/www/foobar; index index.html; > try_files $uri $uri/ /index.html; } | The "^~" location modifier is for prefix-match locations to prevent further checking of regular expressions, see http://nginx.org/r/location for details. If you want to use a regular expression, you have to use the "~" modifier instead. That is, proper configuration will look like: location ~ ^/browser/.*/welcome/welcome.html$ { # URI matches given regular expression ... } location /browser/ { # URI starts with /browser/ ... } location / { # anything else ... } Hope this helps. -- Maxim Dounin http://mdounin.ru/ From community at thoughtmaybe.com Sat Jun 3 21:30:40 2023 From: community at thoughtmaybe.com (Jore) Date: Sun, 4 Jun 2023 07:30:40 +1000 Subject: Regex match the middle of a URL and also the ending? In-Reply-To: References: <41af9ed5-9b7c-ea96-9b47-6658731be92a@thoughtmaybe.com> Message-ID: <8db8bad7-bc07-6092-7ada-ab551b653e04@thoughtmaybe.com> Hi there, Thanks for getting back. On 4/6/23 3:16 am, Maxim Dounin wrote: > Hello! […] > The "^~" location modifier is for prefix-match locations to prevent > further checking of regular expressions, see > http://nginx.org/r/location for details. If you want to use a regular > expression, you have to use the "~" modifier instead. Thank you for that. Apologies, I should’ve mentioned that I did review that documentation on how nginx selects a location. Unfortunately I didn’t find it particularly clear or helpful. I especially thought this rule in question would match and take precedence over the latter /browser rule, because of this line on that page: "If the longest matching prefix location has the “^~” modifier then regular expressions are not checked." i.e. because this rule in question comes first and it is longer than the latter /browser rule, a match would occur here and not later (because processing stops here)? And because I couldn’t find much on how nginx handles regex, I ended up checking this question/answer on Stackoverflow. It cleared things up a little, but still made me wonder why my approach didn’t work. Nevertheless, your suggestions to remove the priority prefix |^~| for the second rule fixed the problem, but I still wonder why my approach didn’t work. ;) Speaking of Stackoverflow, I ended up asking the question there also . Not to take this conversation away from this list, but since your answer was helpful, feel free to chime in there too if you’re looking for some upvotes :) Thanks, Jore ​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Sun Jun 4 00:09:00 2023 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sun, 4 Jun 2023 03:09:00 +0300 Subject: Regex match the middle of a URL and also the ending? In-Reply-To: <8db8bad7-bc07-6092-7ada-ab551b653e04@thoughtmaybe.com> References: <41af9ed5-9b7c-ea96-9b47-6658731be92a@thoughtmaybe.com> <8db8bad7-bc07-6092-7ada-ab551b653e04@thoughtmaybe.com> Message-ID: Hello! On Sun, Jun 04, 2023 at 07:30:40AM +1000, Jore wrote: > Hi there, > > Thanks for getting back. > > On 4/6/23 3:16 am, Maxim Dounin wrote: > > > Hello! > > […] > > > The "^~" location modifier is for prefix-match locations to prevent > > further checking of regular expressions, see > > http://nginx.org/r/location for details. If you want to use a regular > > expression, you have to use the "~" modifier instead. > > Thank you for that. Apologies, I should’ve mentioned that I did review > that documentation on how nginx selects a location. Unfortunately I > didn’t find it particularly clear or helpful. > > I especially thought this rule in question would match and take > precedence over the latter /browser rule, because of this line on that page: > > "If the longest matching prefix location has the “^~” modifier then > regular expressions are not checked." > > i.e. because this rule in question comes first and it is longer than the > latter /browser rule, a match would occur here and not later (because > processing stops here)? The most important part is in the following paragraph: A location can either be defined by a prefix string, or by a regular expression. Regular expressions are specified with the preceding “~*” modifier (for case-insensitive matching), or the “~” modifier (for case-sensitive matching). To find location matching a given request, nginx first checks locations defined using the prefix strings (prefix locations). Among them, the location with the longest matching prefix is selected and remembered. Then regular expressions are checked, in the order of their appearance in the configuration file. The search of regular expressions terminates on the first match, and the corresponding configuration is used. If no match with a regular expression is found then the configuration of the prefix location remembered earlier is used. In other words: - Regular expressions are with "~*" and "~" modifiers. Everything else are prefix strings. - For prefix strings, longest matching prefix is used (note that order of prefix locations is not important). - If the longest prefix found does not disable regular expression matching (with the "^~" modifier, as per the quote you've provided), regular expressions are checked in order. As long as a regular expression is matched, nginx will use the corresponding location. If no regular expressions matched, nginx will use the longest matching prefix location. The "location" directive description additionally provides some examples explaining how this all works. Reading the https://nginx.org/en/docs/http/request_processing.html article might be also helpful. > And because I couldn’t find much on how nginx handles regex, I ended up > checking this question/answer > on Stackoverflow. It > cleared things up a little, but still made me wonder why my approach > didn’t work. > > Nevertheless, your suggestions to remove the priority prefix |^~| for > the second rule fixed the problem, but I still wonder why my approach > didn’t work. ;) In your configuration, location ^~ "/browser/.*/welcome/welcome.html" { ... } is a location defined by a prefix string. It will work for requests with the given prefix, such as "/browser/.*/welcome/welcome.html" or "/browser/.*/welcome/welcome.html.foobar". But since it is a prefix string, and not a regular expression, the ".*" characters do not have any special meaning, and matched literally. That is, this location won't match requests to resources like "/browser/foo123/welcome/welcome.html", since these use a different prefix. To make it match requests to "/browser/foo123/welcome/welcome.html", you have to change the location to a location defined by a regular expression. That, you have to change the "^~" modifier to "~" modifier (and it is also a good idea to change the regular expression to a slightly more explicit one, see my initial response). But it is not enough, see below. Similarly, location ^~ /browser { ... } is also a location defined by a prefix string. Further, due to the "^~" modifier, it disables matching of regular expressions, so any request which starts with "/browser" won't be checked against regular expressions. So you have to remove the "^~" modifier if you want nginx to check regular expressions, notably the one in the first location (assuming "^~" is changed to "~"). Hope this helps. -- Maxim Dounin http://mdounin.ru/ From community at thoughtmaybe.com Sun Jun 4 19:36:35 2023 From: community at thoughtmaybe.com (Jore) Date: Mon, 5 Jun 2023 05:36:35 +1000 Subject: Regex match the middle of a URL and also the ending? In-Reply-To: References: <41af9ed5-9b7c-ea96-9b47-6658731be92a@thoughtmaybe.com> <8db8bad7-bc07-6092-7ada-ab551b653e04@thoughtmaybe.com> Message-ID: <1197b8b0-5f44-d10d-f444-44f6ed546b73@thoughtmaybe.com> Hi there, Yes, all that was /very/ helpful, thank you!!! Much appreciated, Jore On 4/6/23 10:09 am, Maxim Dounin wrote: > The most important part is in the following paragraph: > A location can either be defined by a prefix string, or by a > regular expression. Regular expressions are specified with the > preceding “~*” modifier (for case-insensitive matching), or the > “~” modifier (for case-sensitive matching). To find location > matching a given request, nginx first checks locations defined > using the prefix strings (prefix locations). Among them, the > location with the longest matching prefix is selected and > remembered. Then regular expressions are checked, in the order of > their appearance in the configuration file. The search of regular > expressions terminates on the first match, and the corresponding > configuration is used. If no match with a regular expression is > found then the configuration of the prefix location remembered > earlier is used. > > In other words: > > - Regular expressions are with "~*" and "~" modifiers. Everything > else are prefix strings. > > - For prefix strings, longest matching prefix is used (note that > order of prefix locations is not important). > > - If the longest prefix found does not disable regular expression > matching (with the "^~" modifier, as per the quote you've > provided), regular expressions are checked in order. > > As long as a regular expression is matched, nginx will use the > corresponding location. If no regular expressions matched, nginx > will use the longest matching prefix location. > > The "location" directive description additionally provides some > examples explaining how this all works. Reading the > https://nginx.org/en/docs/http/request_processing.html article > might be also helpful. > >> And because I couldn’t find much on how nginx handles regex, I ended up >> checking this question/answer >> on Stackoverflow. It >> cleared things up a little, but still made me wonder why my approach >> didn’t work. >> >> Nevertheless, your suggestions to remove the priority prefix |^~| for >> the second rule fixed the problem, but I still wonder why my approach >> didn’t work. ;) > In your configuration, > > location ^~ "/browser/.*/welcome/welcome.html" { ... } > > is a location defined by a prefix string. > > It will work for requests with the given prefix, such as > "/browser/.*/welcome/welcome.html" or > "/browser/.*/welcome/welcome.html.foobar". But since it is a > prefix string, and not a regular expression, the ".*" characters > do not have any special meaning, and matched literally. That > is, this location won't match requests to resources like > "/browser/foo123/welcome/welcome.html", since these use a > different prefix. > > To make it match requests to > "/browser/foo123/welcome/welcome.html", you have to change the > location to a location defined by a regular expression. That, you > have to change the "^~" modifier to "~" modifier (and it is also a > good idea to change the regular expression to a slightly more > explicit one, see my initial response). But it is not enough, see > below. > > Similarly, > > location ^~ /browser { ... } > > is also a location defined by a prefix string. Further, due to > the "^~" modifier, it disables matching of regular expressions, so > any request which starts with "/browser" won't be checked against > regular expressions. So you have to remove the "^~" modifier if > you want nginx to check regular expressions, notably the one in > the first location (assuming "^~" is changed to "~"). > > Hope this helps. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cello86 at gmail.com Fri Jun 9 13:10:38 2023 From: cello86 at gmail.com (Marcello Lorenzi) Date: Fri, 9 Jun 2023 15:10:38 +0200 Subject: Nginx Ja3 fingeprint support Message-ID: Hi All, we tried to install an updated module for the SSL fingerprint in Nginx https://github.com/salesforce/ja3 but some modules like https://github.com/phuslu/nginx-ssl-fingerprint aren't compatible with OpenSSL 3. Could you help us if it's possible to configure this fingerprint implementation? Thanks, Marcello -------------- next part -------------- An HTML attachment was scrubbed... URL: From lty at cndns.com Tue Jun 13 02:18:44 2023 From: lty at cndns.com (lty at cndns.com) Date: Tue, 13 Jun 2023 10:18:44 +0800 Subject: nginx mail =?UTF-8?Q?auth=5Fhttp=20response=20support=20ssl=3F?= Message-ID: <9f8b6518099011eea1960026b95c99cc@cndns.com> I want the response to support ssl, is there a way to achieve it? HTTP/1.0 200 OK Auth-Status: OK Auth-Server: 198.51.100.1 Auth-Port: 143 add parameter Auth-Ssl: on ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Tue Jun 13 16:08:12 2023 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 13 Jun 2023 19:08:12 +0300 Subject: nginx mail auth_http response support ssl? In-Reply-To: <9f8b6518099011eea1960026b95c99cc@cndns.com> References: <9f8b6518099011eea1960026b95c99cc@cndns.com> Message-ID: Hello! On Tue, Jun 13, 2023 at 10:18:44AM +0800, lty at cndns.com wrote: > I want the response to support ssl, is there a way to achieve it? > > HTTP/1.0 200 OK > > Auth-Status: OK > > Auth-Server: 198.51.100.1 > > Auth-Port: 143 > > add parameter Auth-Ssl: on ? The mail proxy module in nginx is designed to work with backend servers in trusted environment, and does not provide a direct way to establish SSL connections to backend servers. If you want nginx to use SSL when connecting to backend servers, consider using an SSL tunnel to do so. For example, you can make one with the stream module, see here for details: http://nginx.org/en/docs/stream/ngx_stream_proxy_module.html -- Maxim Dounin http://mdounin.ru/ From mdounin at mdounin.ru Tue Jun 13 16:42:35 2023 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 13 Jun 2023 19:42:35 +0300 Subject: nginx-1.25.1 Message-ID: Changes with nginx 1.25.1 13 Jun 2023 *) Feature: the "http2" directive, which enables HTTP/2 on a per-server basis; the "http2" parameter of the "listen" directive is now deprecated. *) Change: HTTP/2 server push support has been removed. *) Change: the deprecated "ssl" directive is not supported anymore. *) Bugfix: in HTTP/3 when using OpenSSL. -- Maxim Dounin http://nginx.org/ From lty at cndns.com Wed Jun 14 01:13:30 2023 From: lty at cndns.com (lty at cndns.com) Date: Wed, 14 Jun 2023 09:13:30 +0800 Subject: nginx mail =?UTF-8?Q?auth=5Fhttp=20response=20support=20ssl?= =?UTF-8?Q?=3F?= In-Reply-To: <8643cf180a0411eea9dfd4ae5272ffe474863@nginx.org> References: <9f8b6518099011eea1960026b95c99cc@cndns.com> <8643cf180a0411eea9dfd4ae5272ffe474863@nginx.org> Message-ID: Thanks for your suggestion, I'll try another way. --- > Hello! > > On Tue, Jun 13, 2023 at 10:18:44AM +0800, lty at cndns.com wrote: > >> I want the response to support ssl, is there a way to achieve it? HTTP/1.0 200 OK Auth-Status: OK Auth-Server: 198.51.100.1 Auth-Port: 143 add parameter Auth-Ssl: on ? > > The mail proxy module in nginx is designed to work with backend > servers in trusted environment, and does not provide a direct way > to establish SSL connections to backend servers. > > If you want nginx to use SSL when connecting to backend servers, > consider using an SSL tunnel to do so. For example, you can make > one with the stream module, see here for details: > > http://nginx.org/en/docs/stream/ngx_stream_proxy_module.html [1] Links: ------ [1] http://nginx.org/en/docs/stream/ngx_stream_proxy_module.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbravo at colombiahosting.com.co Sat Jun 17 15:25:25 2023 From: jbravo at colombiahosting.com.co (Jose David Bravo A) Date: Sat, 17 Jun 2023 10:25:25 -0500 (COT) Subject: Reverse proxy with URLs replacement Message-ID: <2094574811.105230.1687015525089.JavaMail.zimbra@colombiahosting.com.co> Hello, Is it possible to use Nginx as a proxy for another website, while also having the ability to replace absolute paths in CSS, JS, and HTML content? For example, I would like to have an Nginx server running at the URL http://proxy1-server.com that proxies a web server running at the URL http://192.168.10.10 (private IP). The web server could be any server such as Apache, LiteSpeed, IIS, etc. I can achieve this using an Nginx reverse proxy, but I would also like to rewrite the absolute URLs within the CSS, JS, and HTML files from http://192.168.10.10/file.css to http://proxy1-server.com/file.css, in order to avoid any functionality issues when accessing the website from outside the network. The idea is to replace these URLs within the proxy server itself, rather than modifying the web server where the website is hosted. Thank you! Jose David Bravo Álvarez -------------- next part -------------- An HTML attachment was scrubbed... URL: From r at roze.lv Mon Jun 19 06:25:16 2023 From: r at roze.lv (Reinis Rozitis) Date: Mon, 19 Jun 2023 09:25:16 +0300 Subject: Reverse proxy with URLs replacement In-Reply-To: <2094574811.105230.1687015525089.JavaMail.zimbra@colombiahosting.com.co> References: <2094574811.105230.1687015525089.JavaMail.zimbra@colombiahosting.com.co> Message-ID: <004e01d9a276$d0375c70$70a61550$@roze.lv> > Is it possible to use Nginx as a proxy for another website, while also having the ability to replace absolute paths in CSS, JS, and HTML content? One way for that is to use proxy http://nginx.org/en/docs/http/ngx_http_proxy_module.html + sub module http://nginx.org/en/docs/http/ngx_http_sub_module.html The only caveat is that the sub module doesn't support compressed responses from backends so you need to switch it off by setting proxy_set_header Accept-Encoding ""; rr From y.abadi at f5.com Wed Jun 21 11:36:54 2023 From: y.abadi at f5.com (Yuval Abadi) Date: Wed, 21 Jun 2023 11:36:54 +0000 Subject: nginx_http_write_filter_module.c Message-ID: Hi. Nginx 1.23.2 The cpi ngx_http_write_filter(ngx_http_request_t *r, ngx_chain_t *in) Loop over the request out buffers and in chain If calculate size of combined buffer to write. I add body replacement on chain. It have value, but ngx_buf_size(cl->buf); Return it have 0. Size. (l->buf->last - cl->buf->pos) give the correct size So the buffer not written. Only the header part send back to client Any idea? 023/06/21 10:45:31 [debug] 22962#22962: *3 write old buf t:1 f:0 00005600970D81E0, pos 00005600970D81E0, size: 179 file: 0, size: 0 2023/06/21 10:45:31 [debug] 22962#22962: *3 write new buf t:0 f:0 00005600970D8098, pos 00005600970D8098, size: 247 file: 0, size: 0 2023/06/21 10:45:31 [debug] 22962#22962: *3 http write filter: l:1 f:0 s:179 2023/06/21 10:45:31 [debug] 22962#22962: *3 http write filter limit 2097152 2023/06/21 10:45:31 [debug] 22962#22962: *3 writev: 179 of 179 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Wed Jun 21 16:01:26 2023 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 21 Jun 2023 19:01:26 +0300 Subject: nginx_http_write_filter_module.c In-Reply-To: References: Message-ID: Hello! On Wed, Jun 21, 2023 at 11:36:54AM +0000, Yuval Abadi via nginx wrote: > Nginx 1.23.2 > > The cpi ngx_http_write_filter(ngx_http_request_t *r, ngx_chain_t *in) > > Loop over the request out buffers and in chain > > If calculate size of combined buffer to write. > > I add body replacement on chain. > It have value, but ngx_buf_size(cl->buf); > Return it have 0. Size. > > (l->buf->last - cl->buf->pos) give the correct size > > So the buffer not written. > > Only the header part send back to client > > Any idea? > > 2023/06/21 10:45:31 [debug] 22962#22962: *3 write old buf t:1 f:0 00005600970D81E0, pos 00005600970D81E0, size: 179 file: 0, size: 0 > 2023/06/21 10:45:31 [debug] 22962#22962: *3 write new buf t:0 f:0 00005600970D8098, pos 00005600970D8098, size: 247 file: 0, size: 0 > 2023/06/21 10:45:31 [debug] 22962#22962: *3 http write filter: l:1 f:0 s:179 > 2023/06/21 10:45:31 [debug] 22962#22962: *3 http write filter limit 2097152 > 2023/06/21 10:45:31 [debug] 22962#22962: *3 writev: 179 of 179 Note the "t:0" part in the relevant debug log line: it suggests that the cl->buf->temporary flag is not set. If the cl->buf->memory flag isn't set as well, this basically means that buffer does not reference any memory at all (even if cl->buf->post / cl->buf->last pointers are set). For such a buffer ngx_buf_size() will return the file size. And, since the buffer does not reference file data as well (note "f:0"), it is expected to be 0 (and it is, as per "file: 0, size: 0"). So it looks like the behaviour you observe is the result of forgotten cl->buf->memory (or cl->buf->temporary) flag. Check your code to see if the buffer flags are set correctly, it looks like they aren't. See http://nginx.org/en/docs/dev/development_guide.html#buffer for basic information about memory buffers and some basic examples. For additional information, check nginx code. -- Maxim Dounin http://mdounin.ru/ From y.abadi at f5.com Tue Jun 27 10:52:52 2023 From: y.abadi at f5.com (Yuval Abadi) Date: Tue, 27 Jun 2023 10:52:52 +0000 Subject: nginx_http_write_filter_module.c In-Reply-To: References: Message-ID: Thanks From: nginx on behalf of Maxim Dounin Date: Wednesday, 21 June 2023 at 19:01 To: Yuval Abadi via nginx Subject: Re: nginx_http_write_filter_module.c EXTERNAL MAIL: nginx-bounces at nginx.org Hello! On Wed, Jun 21, 2023 at 11:36:54AM +0000, Yuval Abadi via nginx wrote: > Nginx 1.23.2 > > The cpi ngx_http_write_filter(ngx_http_request_t *r, ngx_chain_t *in) > > Loop over the request out buffers and in chain > > If calculate size of combined buffer to write. > > I add body replacement on chain. > It have value, but ngx_buf_size(cl->buf); > Return it have 0. Size. > > (l->buf->last - cl->buf->pos) give the correct size > > So the buffer not written. > > Only the header part send back to client > > Any idea? > > 2023/06/21 10:45:31 [debug] 22962#22962: *3 write old buf t:1 f:0 00005600970D81E0, pos 00005600970D81E0, size: 179 file: 0, size: 0 > 2023/06/21 10:45:31 [debug] 22962#22962: *3 write new buf t:0 f:0 00005600970D8098, pos 00005600970D8098, size: 247 file: 0, size: 0 > 2023/06/21 10:45:31 [debug] 22962#22962: *3 http write filter: l:1 f:0 s:179 > 2023/06/21 10:45:31 [debug] 22962#22962: *3 http write filter limit 2097152 > 2023/06/21 10:45:31 [debug] 22962#22962: *3 writev: 179 of 179 Note the "t:0" part in the relevant debug log line: it suggests that the cl->buf->temporary flag is not set. If the cl->buf->memory flag isn't set as well, this basically means that buffer does not reference any memory at all (even if cl->buf->post / cl->buf->last pointers are set). For such a buffer ngx_buf_size() will return the file size. And, since the buffer does not reference file data as well (note "f:0"), it is expected to be 0 (and it is, as per "file: 0, size: 0"). So it looks like the behaviour you observe is the result of forgotten cl->buf->memory (or cl->buf->temporary) flag. Check your code to see if the buffer flags are set correctly, it looks like they aren't. See https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnginx.org%2Fen%2Fdocs%2Fdev%2Fdevelopment_guide.html%23buffer&data=05%7C01%7Cy.abadi%40f5.com%7C93490412a0ae47a77b2808db7270cf46%7Cdd3dfd2f6a3b40d19be0bf8327d81c50%7C0%7C0%7C638229601077880722%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lfQi%2FWoc7nk3Zr8R6I1X9DAE%2BZ36sfkMT6%2Fnw7YFgR8%3D&reserved=0 for basic information about memory buffers and some basic examples. For additional information, check nginx code. -- Maxim Dounin https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmdounin.ru%2F&data=05%7C01%7Cy.abadi%40f5.com%7C93490412a0ae47a77b2808db7270cf46%7Cdd3dfd2f6a3b40d19be0bf8327d81c50%7C0%7C0%7C638229601077880722%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rrIFE5kKXycRGSmQ64bP%2BwDfaqpEVKZfndVRYmgxNyE%3D&reserved=0 _______________________________________________ nginx mailing list nginx at nginx.org https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.nginx.org%2Fmailman%2Flistinfo%2Fnginx&data=05%7C01%7Cy.abadi%40f5.com%7C93490412a0ae47a77b2808db7270cf46%7Cdd3dfd2f6a3b40d19be0bf8327d81c50%7C0%7C0%7C638229601077880722%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=R77KnZSvlfE6Uy7%2BHMZ5FwuvhKWrNJboV3tkV%2Frm2wc%3D&reserved=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From y.abadi at f5.com Tue Jun 27 10:57:37 2023 From: y.abadi at f5.com (Yuval Abadi) Date: Tue, 27 Jun 2023 10:57:37 +0000 Subject: chunk body in response Message-ID: Hi Nginx 1.23.2 When HTTP Server replies chunk body nginx has an error 0 upstream sent invalid chunked response while reading upstream, client: 10.1.0.14, server: , request: My nginx.conf have these attribute under the server section: + proxy_http_version 1.1; + proxy_set_header Connection ""; What am I Missing? Is new/other Nginx version solving this issue? Thanks Yuval Abadi -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Tue Jun 27 21:14:29 2023 From: mdounin at mdounin.ru (Maxim Dounin) Date: Wed, 28 Jun 2023 00:14:29 +0300 Subject: chunk body in response In-Reply-To: References: Message-ID: Hello! On Tue, Jun 27, 2023 at 10:57:37AM +0000, Yuval Abadi via nginx wrote: > Hi > > Nginx 1.23.2 > > When HTTP Server replies chunk body nginx has an error > 0 upstream sent invalid chunked response while reading upstream, client: 10.1.0.14, server: , request: > > My nginx.conf have these attribute under the server section: > > + proxy_http_version 1.1; > + proxy_set_header Connection ""; > > What am I Missing? > Is new/other Nginx version solving this issue? The error message suggests your upstream server returned an invalid response. Check nginx debug logs and/or tcpdump for more details (and probably some hints on how to fix your upstream server). -- Maxim Dounin http://mdounin.ru/ From fusca14 at gmail.com Wed Jun 28 20:19:55 2023 From: fusca14 at gmail.com (Fabiano Furtado Pessoa Coelho) Date: Wed, 28 Jun 2023 17:19:55 -0300 Subject: NGINX 1.23.4 warning message Message-ID: Hi... Recently, I've upgrade my NGINX version 1.22.x to 1.24.0 and I notice in nginx.org/en/CHANGES-1.24 about a new change in version 1.23.4: "Changes with nginx 1.23.4 28 Mar 2023 ... *) Change: now nginx issues a warning if protocol parameters of a listening socket are redefined. ..." I have the following configuration, using distinct "server" blocks server { listen : ssl http2; ...} server { listen : ssl; ...} # listen definition without "http2" ... and the following warning messages (it appears in "error.log" file too): # nginx -t: nginx: [warn] protocol options redefined for : in /etc/nginx/conf.d/servers.conf:"x" nginx: [warn] protocol options redefined for : in /etc/nginx/conf.d/servers.conf:"y" What do these warning messages mean? Should I be worried? Thanks in advance. Fabiano Furtado From osa at freebsd.org.ru Thu Jun 29 01:02:53 2023 From: osa at freebsd.org.ru (Sergey A. Osokin) Date: Thu, 29 Jun 2023 04:02:53 +0300 Subject: NGINX 1.23.4 warning message In-Reply-To: References: Message-ID: Hi Fabiano, On Wed, Jun 28, 2023 at 05:19:55PM -0300, Fabiano Furtado Pessoa Coelho wrote: > > Changes with nginx 1.23.4 28 Mar 2023 > > *) Change: now nginx issues a warning if protocol parameters > of a listening socket are redefined. [...] > What do these warning messages mean? Should I be worried? >From the provided configuration snippet it's unclear is the same ip:port pairs for two server blocks. In case those are - all servers are listening on the same ip:port should have the same parameters. To avoid such a warning update parameters for the listen directive in the second server block. -- Sergey A. Osokin From fusca14 at gmail.com Thu Jun 29 14:00:21 2023 From: fusca14 at gmail.com (Fabiano Furtado Pessoa Coelho) Date: Thu, 29 Jun 2023 11:00:21 -0300 Subject: NGINX 1.23.4 warning message In-Reply-To: References: Message-ID: On Wed, Jun 28, 2023 at 10:03 PM Sergey A. Osokin wrote: > > Hi Fabiano, Hi... > On Wed, Jun 28, 2023 at 05:19:55PM -0300, Fabiano Furtado Pessoa Coelho wrote: > > > > Changes with nginx 1.23.4 28 Mar 2023 > > > > *) Change: now nginx issues a warning if protocol parameters > > of a listening socket are redefined. > > [...] > > > What do these warning messages mean? Should I be worried? > > From the provided configuration snippet it's unclear is the same > ip:port pairs for two server blocks. In case those are - all > servers are listening on the same ip:port should have the same > parameters. To avoid such a warning update parameters for the > listen directive in the second server block. OK. The IPs and ports are the same. However, if I continue to use exactly this configuration, are there any possible technical issues (I don't think so, because it is a "warning".) with this environment? Sorry, but I think I wasn't clear enough with my question. Thanks. > Sergey A. Osokin > _______________________________________________ From francis at daoine.org Thu Jun 29 14:26:49 2023 From: francis at daoine.org (Francis Daly) Date: Thu, 29 Jun 2023 15:26:49 +0100 Subject: NGINX 1.23.4 warning message In-Reply-To: References: Message-ID: <20230629142649.GV15845@daoine.org> On Thu, Jun 29, 2023 at 11:00:21AM -0300, Fabiano Furtado Pessoa Coelho wrote: > On Wed, Jun 28, 2023 at 10:03 PM Sergey A. Osokin wrote: > > On Wed, Jun 28, 2023 at 05:19:55PM -0300, Fabiano Furtado Pessoa Coelho wrote: Hi there, > > > Changes with nginx 1.23.4 28 Mar 2023 > > > > > > *) Change: now nginx issues a warning if protocol parameters > > > of a listening socket are redefined. > > > > [...] > > > > > What do these warning messages mean? Should I be worried? > > > > From the provided configuration snippet it's unclear is the same > > ip:port pairs for two server blocks. In case those are - all > > servers are listening on the same ip:port should have the same > > parameters. To avoid such a warning update parameters for the > > listen directive in the second server block. > > OK. The IPs and ports are the same. However, if I continue to use > exactly this configuration, are there any possible technical issues (I > don't think so, because it is a "warning".) with this environment? > Sorry, but I think I wasn't clear enough with my question. I think the point is: your config makes it look like you want one server to use ssl-and-http2, and you want the other server to use ssl-without-http2. That is not how it works; and that is never how it worked. So a naïve reading of your config might lead the reader to be unclear about what exactly each server is actually using. This new warning is telling you "your config might be misleading". It is still doing exactly what it always was doing (and: I guess it will continue to do that in future updates; but nothing is guaranteed). It is additionally letting you know of this possibly-unintentional config, so you can choose to leave it as-is (and get the warnings on startup) or you can choose to make it explicit that you know what settings apply to (this ip:port in) each server. Cheers, f -- Francis Daly francis at daoine.org From fusca14 at gmail.com Thu Jun 29 19:29:39 2023 From: fusca14 at gmail.com (Fabiano Furtado Pessoa Coelho) Date: Thu, 29 Jun 2023 16:29:39 -0300 Subject: Possible bug with "proxy_intercept_errors on; " + "error_page 301 302"? Message-ID: Hi... I have one peculiar issue with NGINX 1.22.0 + "proxy_intercept_errors on;" + custom 302 "error_page". Here is my simplified NGINX config: http { error_page 301 302 /30x.html; server { location /30x.html { root /etc/nginx/custom_error_pages; sub_filter_once off; sub_filter '*HTTP_STATUS_CODE*' '$status'; internal; } location /mysystem { rewrite ^(.*)$ / break; # remove "/mysystem" and only send "/" to backend proxy_intercept_errors on; proxy_pass http://php_server; } } } Using both "proxy_intercept_errors on;" and "error_page" directive, I have HTTP 302 response from my php backend server (OK!), but without HTTP new "location" header: $ curl -v https://foo/mysystem ... < HTTP/2 302 < date: Thu, 29 Jun 2023 17:48:31 GMT < content-type: text/html < strict-transport-security: max-age=63072000 ... Why? If I turn off the "proxy_intercept_errors" directive or remove the line "error_page 301 302 /30x.html;", it works: $ curl -v https://foo/mysystem ... < HTTP/2 302 < date: Thu, 29 Jun 2023 18:05:42 GMT < content-type: text/html; charset=UTF-8 < location: https://bar < strict-transport-security: max-age=63072000 ... Is this normal? Why can't I have a 302 custom error page using "proxy_intercept_errors on;"? Thanks in advance. From mdounin at mdounin.ru Thu Jun 29 22:00:04 2023 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 30 Jun 2023 01:00:04 +0300 Subject: Possible bug with "proxy_intercept_errors on; " + "error_page 301 302"? In-Reply-To: References: Message-ID: Hello! On Thu, Jun 29, 2023 at 04:29:39PM -0300, Fabiano Furtado Pessoa Coelho wrote: > Hi... > > I have one peculiar issue with NGINX 1.22.0 + "proxy_intercept_errors > on;" + custom 302 "error_page". > > Here is my simplified NGINX config: > > http { > error_page 301 302 /30x.html; > server { > location /30x.html { > root /etc/nginx/custom_error_pages; > sub_filter_once off; > sub_filter '*HTTP_STATUS_CODE*' '$status'; > internal; > } > location /mysystem { > rewrite ^(.*)$ / break; # remove "/mysystem" and only send "/" to backend > proxy_intercept_errors on; > proxy_pass http://php_server; > } > } > } > > Using both "proxy_intercept_errors on;" and "error_page" directive, I > have HTTP 302 response from my php backend server (OK!), but without > HTTP new "location" header: > > $ curl -v https://foo/mysystem > ... > < HTTP/2 302 > < date: Thu, 29 Jun 2023 17:48:31 GMT > < content-type: text/html > < strict-transport-security: max-age=63072000 > ... > > Why? If I turn off the "proxy_intercept_errors" directive or remove > the line "error_page 301 302 /30x.html;", it works: > > $ curl -v https://foo/mysystem > ... > < HTTP/2 302 > < date: Thu, 29 Jun 2023 18:05:42 GMT > < content-type: text/html; charset=UTF-8 > < location: https://bar > < strict-transport-security: max-age=63072000 > ... > > Is this normal? Why can't I have a 302 custom error page using > "proxy_intercept_errors on;"? The "proxy_intercept_errors" handling does not copy any response headers from the original response (the only exception is WWW-Authenticate for 403 responses). If you want nginx to copy some headers, consider doing it yourself with the $upstream_http_* variables and the add_header directive. Something like this should work: location /30x.html { add_header Location $upstream_http_location; ... } Note though that you'll have to manually rewrite location if needed (as proxy_redirect handling won't be used). -- Maxim Dounin http://mdounin.ru/ From fusca14 at gmail.com Thu Jun 29 22:10:37 2023 From: fusca14 at gmail.com (Fabiano Furtado Pessoa Coelho) Date: Thu, 29 Jun 2023 19:10:37 -0300 Subject: Possible bug with "proxy_intercept_errors on; " + "error_page 301 302"? In-Reply-To: References: Message-ID: Thanks! I'm gonna try this approach. On Thu, Jun 29, 2023 at 7:00 PM Maxim Dounin wrote: > > Hello! > > On Thu, Jun 29, 2023 at 04:29:39PM -0300, Fabiano Furtado Pessoa Coelho wrote: ... > > The "proxy_intercept_errors" handling does not copy any response > headers from the original response (the only exception is > WWW-Authenticate for 403 responses). > > If you want nginx to copy some headers, consider doing it yourself > with the $upstream_http_* variables and the add_header directive. > Something like this should work: > > location /30x.html { > add_header Location $upstream_http_location; > ... > } > > Note though that you'll have to manually rewrite location if > needed (as proxy_redirect handling won't be used). From sten.gruener at gmail.com Fri Jun 30 09:29:21 2023 From: sten.gruener at gmail.com (Sten Gruener) Date: Fri, 30 Jun 2023 11:29:21 +0200 Subject: Mixing limit_except breaks rewrite functionality: workaround request Message-ID: Dear all, I trying to mix authentication for POST requests with some rewrite/proxy_pass logic. This mean that password is required only on POST/PUT requests. location /x/ { limit_except GET OPTIONS { auth_basic "Write Access"; auth_basic_user_file /etc/nginx/conf.d/htpasswd_write; } rewrite ^ $request_uri; rewrite ^/x/(.*) $1 break; return 400; proxy_pass http://server:8081/$uri; } The snipped above is not working to to the bug/feature which is known: https://trac.nginx.org/nginx/ticket/1383 Could someone please provide guidance of whether it is possible to implement my goal using the proposed map directive from the ticket itself? BR and Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From mauro.tridici at cmcc.it Fri Jun 30 14:17:38 2023 From: mauro.tridici at cmcc.it (Mauro Tridici) Date: Fri, 30 Jun 2023 16:17:38 +0200 Subject: Accessing electronic resources from outside the corporate network: Proxy or VPN? Message-ID: <68D16FC8-589F-4B2C-9D91-C895847357F6@cmcc.it> Dear Users, my boss asked me to implemented a proxy service in order to allow corporate users to access electronic resources, subscribed by our company, also from outside the corporate network (you know, users can work both from office and from home). Unfortunately, I’m a newbie and I’m a little bit confused. Surfing on the web, I read that: - proxy is not a secure choice; - all the web traffic generated by the users working from home will overload the proxy; - proxy is not able to encrypt the internet traffic; From the other side, a VPN seems to be the preferred solution: - VPN provides better performance and security level; - VPN solution assumes a strong authentication process; - VPN can be used to route only specific traffic/IP addresses through VPN tunnel Are these assumptions true? Can I use NGINX to implemented the needed proxy? Or should I prefer the VPN based solution. What are your suggestions about this scenario? Have you had any experience with such a topic? Could you please help me to identify the right solution and best (implementation) practices? If you have any reference links to study, please feel free to share them. Many thank in advance, Mauro From teward at thomas-ward.net Fri Jun 30 14:19:31 2023 From: teward at thomas-ward.net (Thomas Ward) Date: Fri, 30 Jun 2023 14:19:31 +0000 Subject: Accessing electronic resources from outside the corporate network: Proxy or VPN? In-Reply-To: <68D16FC8-589F-4B2C-9D91-C895847357F6@cmcc.it> References: <68D16FC8-589F-4B2C-9D91-C895847357F6@cmcc.it> Message-ID: I would not consider NGINX a proxy in the form you're looking for - it's not designed to work as a "proxy" server in the sense of what you're looking for, and VPN + internal proxy is the better solution for access to resources subscribed to a company (but that's outside the scope of NGINX and is more my opinion as a security guy). Thomas -----Original Message----- From: nginx On Behalf Of Mauro Tridici Sent: Friday, June 30, 2023 10:18 AM To: nginx at nginx.org Subject: Accessing electronic resources from outside the corporate network: Proxy or VPN? Dear Users, my boss asked me to implemented a proxy service in order to allow corporate users to access electronic resources, subscribed by our company, also from outside the corporate network (you know, users can work both from office and from home). Unfortunately, I’m a newbie and I’m a little bit confused. Surfing on the web, I read that: - proxy is not a secure choice; - all the web traffic generated by the users working from home will overload the proxy; - proxy is not able to encrypt the internet traffic; From the other side, a VPN seems to be the preferred solution: - VPN provides better performance and security level; - VPN solution assumes a strong authentication process; - VPN can be used to route only specific traffic/IP addresses through VPN tunnel Are these assumptions true? Can I use NGINX to implemented the needed proxy? Or should I prefer the VPN based solution. What are your suggestions about this scenario? Have you had any experience with such a topic? Could you please help me to identify the right solution and best (implementation) practices? If you have any reference links to study, please feel free to share them. Many thank in advance, Mauro _______________________________________________ nginx mailing list nginx at nginx.org https://mailman.nginx.org/mailman/listinfo/nginx From mauro.tridici at cmcc.it Fri Jun 30 14:32:30 2023 From: mauro.tridici at cmcc.it (Mauro Tridici) Date: Fri, 30 Jun 2023 16:32:30 +0200 Subject: Accessing electronic resources from outside the corporate network: Proxy or VPN? In-Reply-To: References: <68D16FC8-589F-4B2C-9D91-C895847357F6@cmcc.it> Message-ID: <1124E2E4-4D18-4924-AB03-F349113E5C04@cmcc.it> Thank you for you reply, Thomas. My boss also pointed me to the name of EZproxy. But I'm with you and with your suggestion. Do you know of any forums or communities, dedicated to security, from which you can extract information regarding the pros and cons of using proxies or VPN? Mauro > On 30 Jun 2023, at 16:19, Thomas Ward wrote: > > I would not consider NGINX a proxy in the form you're looking for - it's not designed to work as a "proxy" server in the sense of what you're looking for, and VPN + internal proxy is the better solution for access to resources subscribed to a company (but that's outside the scope of NGINX and is more my opinion as a security guy). > > Thomas > > > -----Original Message----- > From: nginx On Behalf Of Mauro Tridici > Sent: Friday, June 30, 2023 10:18 AM > To: nginx at nginx.org > Subject: Accessing electronic resources from outside the corporate network: Proxy or VPN? > > Dear Users, > > my boss asked me to implemented a proxy service in order to allow corporate users to access electronic resources, subscribed by our company, also from outside the corporate network (you know, users can work both from office and from home). > Unfortunately, I’m a newbie and I’m a little bit confused. > Surfing on the web, I read that: > > - proxy is not a secure choice; > - all the web traffic generated by the users working from home will overload the proxy; > - proxy is not able to encrypt the internet traffic; > > From the other side, a VPN seems to be the preferred solution: > > - VPN provides better performance and security level; > - VPN solution assumes a strong authentication process; > - VPN can be used to route only specific traffic/IP addresses through VPN tunnel > > Are these assumptions true? Can I use NGINX to implemented the needed proxy? Or should I prefer the VPN based solution. > What are your suggestions about this scenario? Have you had any experience with such a topic? > > Could you please help me to identify the right solution and best (implementation) practices? > If you have any reference links to study, please feel free to share them. > > Many thank in advance, > Mauro > _______________________________________________ > nginx mailing list > nginx at nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx From fusca14 at gmail.com Fri Jun 30 16:24:18 2023 From: fusca14 at gmail.com (Fabiano Furtado Pessoa Coelho) Date: Fri, 30 Jun 2023 13:24:18 -0300 Subject: Possible bug with "proxy_intercept_errors on; " + "error_page 301 302"? In-Reply-To: References: Message-ID: Hello Maxim... On Thu, Jun 29, 2023 at 7:00 PM Maxim Dounin wrote: > > Hello! > > On Thu, Jun 29, 2023 at 04:29:39PM -0300, Fabiano Furtado Pessoa Coelho wrote: > > > Hi... ... > > "proxy_intercept_errors on;"? > > The "proxy_intercept_errors" handling does not copy any response > headers from the original response (the only exception is > WWW-Authenticate for 403 responses). > > If you want nginx to copy some headers, consider doing it yourself > with the $upstream_http_* variables and the add_header directive. > Something like this should work: > > location /30x.html { > add_header Location $upstream_http_location; > ... > } > > Note though that you'll have to manually rewrite location if > needed (as proxy_redirect handling won't be used). Your approach worked fine for me! Thanks for the help. Horever, without this "add_header" modification and with "proxy_intercept_errors on;", I've two situations: * without "error_page 301 302 /30x.html;" directive configured: I receive the HTTP "location" header from my NGINX; * with "error_page 301 302 /30x.html;" directive configured: I don't receive the HTTP "location" header from my NGINX; If "proxy_intercept_errors" handling does not copy any response headers from the original response, why is this HTTP "location" header present with "error_page 301 302 /30x.html;" directive configured in my system? I really don't understand why it happens. Well, thanks again. Fabiano From Sam at SimpleSamples.info Fri Jun 30 19:46:35 2023 From: Sam at SimpleSamples.info (Sam Hobbs) Date: Fri, 30 Jun 2023 12:46:35 -0700 Subject: Documentation of Nginx configuration file directives Message-ID: <16130714-530c-6586-311c-23229d98f49f@SimpleSamples.info> Is there official documentation of the nginx configuration file directives? I find many articles describing nginx configuration files but they do not describe all of the directives, certainly not like official documentation typically does. From maxim at nginx.com Fri Jun 30 19:59:09 2023 From: maxim at nginx.com (Maxim Konovalov) Date: Fri, 30 Jun 2023 12:59:09 -0700 Subject: Documentation of Nginx configuration file directives In-Reply-To: <16130714-530c-6586-311c-23229d98f49f@SimpleSamples.info> References: <16130714-530c-6586-311c-23229d98f49f@SimpleSamples.info> Message-ID: <78e3b2d3-79fb-d5e1-b9ec-99721f616a0e@nginx.com> Hi Sam, On 30.06.2023 12:46, Sam Hobbs wrote: > Is there official documentation of the nginx configuration file > directives? I find many articles describing nginx configuration files > but they do not describe all of the directives, certainly not like > official documentation typically does. The official documentation for nginx config directives is here http://nginx.org/en/docs/ http://nginx.org/en/docs/dirindex.html Please bear in mind that various 3rd party modules may have their own configuration items such as directives and variables or even separate config files and they are not covered by this documentation. Maxim -- Maxim Konovalov