Help: Using Nginx Reverse Proxy bypass traffic in to a application running in a container
Amila Gunathilaka
amila.kdam at gmail.com
Sat May 29 13:41:38 UTC 2021
Hi Francis,
Thanks for your reply email, here are my findings and progress and current
situation about my issue. First of all I will answer your questions and
then you will have a better idea to guide me and whether I'm on the correct
path.
>As I understand it, the load balancer is making the request "OPTIONS /"
>to nginx, and nginx is responding with a http 405, and you don't want
>nginx to do that.
>What response do you want nginx to give to the request?
Yes you are absolutely right I wanted nginx to stop that 405 response and
give the success response 200 or even 401 which I can confirm my proxy pass
and basic auth is working.
Also I think that 405 response is coming *from nginx itself *to the
external load balancer because external load balancer directly
communicating with the nginx (80) and also my upstream server (9091 port
server) is not a webapp it's just a binary file running inside docker
container. But anyway maybe it's coming from the 9091 server app. You
could investigate the 9091 server app here if you are interested -
https://hub.docker.com/r/prom/pushgateway/tags?page=1&ordering=last_updated .
Let me know me as well, weather it's the 9091 app or nginx causing problems
if you can find out.
Anyway I thought to fix the OPTIONS method fix on the external load
balancer itself , and I logged in to my external load balancer configs
page and I changed the HTTP health checks using OPTIONS into *GET *
method.
ANd yeah now 405 error gone. But now I'm getting 401 responses , which
should be the correct response since I'm using a basic auth in my
nginx.conf file. Below is my nginx.conf FYI
worker_rlimit_nofile 30000;
events {
worker_connections 30000;
}
http {
#upstream pushgateway_upstreams {
# server 127.0.0.1:9091;
# }
server {
listen 172.25.234.105:80;
#server_name 172.25.234.105;
location /metrics {
proxy_pass http://127.0.0.1:9091/metrics;
auth_basic "PROMETHEUS PUSHGATEWAY Login Area";
auth_basic_user_file /etc/nginx/.htpasswd;
}
}
}
* So I can confirm that proxy_pass is working because when I browse my
application it returns the 401 message now.
*curl -v http://172.25.234.105:80/metrics
<http://172.25.234.105:80/metrics>*
* Trying 172.25.234.105:80...
* TCP_NODELAY set
* Connected to 172.25.234.105 (172.25.234.105) port 80 (#0)
> GET /metrics HTTP/1.1
> Host: 172.25.234.105
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 401 Unauthorized
< Server: nginx/1.18.0 (Ubuntu)
< Date: Sat, 29 May 2021 13:29:00 GMT
< Content-Type: text/html
< Content-Length: 188
< Connection: keep-alive
< WWW-Authenticate: Basic realm="PROMETHEUS PUSHGATEWAY Login Area"
<
<html>
<head><title>*401 *Authorization Required</title></head>
<body>
<center><h1>*401* Authorization Required</h1></center>
<hr><center>nginx/1.18.0 (Ubuntu)</center>
</body>
</html>
Seems like everything is fine for now. Any questions or any enhancements
are welcome. Thanks Francis.
Thanks
Amila
Devops Engineer
On Fri, May 28, 2021 at 1:30 PM <nginx-request at nginx.org> wrote:
> Send nginx mailing list submissions to
> nginx at nginx.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mailman.nginx.org/mailman/listinfo/nginx
> or, via email, send a message with subject or body 'help' to
> nginx-request at nginx.org
>
> You can reach the person managing the list at
> nginx-owner at nginx.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of nginx digest..."
>
>
> Today's Topics:
>
> 1. Request for comments on Nginx configuration (mandela)
> 2. How to do a large buffer size > 64k uWSGI requests with Nginx
> proxy | uwsgi request is too big with nginx (Rai Mohammed)
> 3. Unit 1.24.0 release (Valentin V. Bartenev)
> 4. Re: How to do a large buffer size > 64k uWSGI requests with
> Nginx proxy | uwsgi request is too big with nginx (Maxim Dounin)
> 5. Re: How to do a large buffer size > 64k uWSGI requests with
> Nginx proxy | uwsgi request is too big with nginx (Rai Mohammed)
> 6. Re: Help: Using Nginx Reverse Proxy bypass traffic in to a
> application running in a container (Francis Daly)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 27 May 2021 14:55:03 -0400
> From: "mandela" <nginx-forum at forum.nginx.org>
> To: nginx at nginx.org
> Subject: Request for comments on Nginx configuration
> Message-ID:
> <
> 978b154f0f2638185fd19dbcca86a663.NginxMailingListEnglish at forum.nginx.org>
>
> Content-Type: text/plain; charset=UTF-8
>
> Hello all. I would like to have comments from the Nginx community on the
> following configuration:
>
> worker_processes auto;
> error_log /var/www/log/nginx.log;
>
> events {
> multi_accept on;
> worker_connections 16384;
> }
>
> http {
> include nginx.deny;
> include mime.types;
> default_type application/octet-stream;
> aio on;
> sendfile on;
> tcp_nopush on;
> gzip on;
> gzip_comp_level 6;
> gzip_min_length 1024;
> gzip_types
> application/javascript
> application/json
> application/xml
> image/svg+xml
> image/x-icon
> text/plain
> text/css
> text/xml
> ;
> lua_shared_dict dict 16k;
> log_format main $time_iso8601
> ' srs="$status"'
> ' srt="$request_time"'
> ' crl="$request"'
> ' crh="$host"'
> ' cad="$remote_addr"'
> ' ssp="$server_port"'
> ' scs="$upstream_cache_status"'
> ' sua="$upstream_addr"'
> ' suc="$upstream_connect_time"'
> ' sut="$upstream_response_time"'
> ' sgz="$gzip_ratio"'
> ' sbs="$body_bytes_sent"'
> ' cau="$remote_user"'
> ' ccr="$connection_requests"'
> ' ccp="$pipe"'
> ' crs="$scheme"'
> ' crm="$request_method"'
> ' cru="$request_uri"'
> ' crp="$server_protocol"'
> ' chh="$http_host"'
> ' cha="$http_user_agent"'
> ' chr="$http_referer"'
> ' chf="$http_x_forwarded_for"'
> ;
> server_tokens off;
> reset_timedout_connection on;
> access_log /var/www/log/access.log main;
>
> fastcgi_cache main;
> fastcgi_cache_key $host:$server_port$uri;
> fastcgi_cache_methods GET HEAD;
> fastcgi_ignore_headers Cache-Control Expires;
> fastcgi_cache_path /tmp/nginx
> levels=2:2
> keys_zone=main:4m
> inactive=24h
> ;
> ssl_certificate /etc/ssl/server.pem;
> ssl_certificate_key /etc/ssl/server.key;
> ssl_prefer_server_ciphers on;
> ssl_session_cache shared:SSL:4m;
> ssl_session_timeout 15m;
>
> upstream upstream {
> server unix:/tmp/php-fpm.sock;
> server 127.0.0.1:9000;
> server [::1]:9000;
> }
>
> map $http_origin $_origin {
> default *;
> '' '';
> }
>
> server {
> listen 80;
> return 301 https://$host$request_uri;
> }
>
> server {
> listen 443 ssl http2;
> include nginx.filter;
> location / {
> set $_v1 '';
> set $_v2 '';
> set $_v3 '';
> rewrite_by_lua_block {
> local dict = ngx.shared.dict
> local host = ngx.var.host
> local data = dict:get(host)
> if data == nil then
> local labels = {}
> for s in host:gmatch('[^.]+') do
> table.insert(labels, 1, s)
> end
> data = labels[1] or ''
> local index = 2
> while index <= #labels and #data <
> 7 do
> data = data .. '/' ..
> labels[index]
> index = index + 1
> end
> local f = '/usr/home/www/src/' ..
> data .. '/app.php'
> local _, _, code = os.rename(f, f)
> if code == 2 then
> return ngx.exit(404)
> end
> if labels[index] == 'cdn' then
> data = data ..
> '|/tmp/www/cdn/' .. data
> else
> data = data ..
> '|/var/www/pub/'
> ..
> table.concat(labels, '/') .. '/-'
> end
> data = data .. '|' .. f
> dict:add(host, data)
> ngx.log(ngx.ERR,
> 'dict:add('..host..','..data..')')
> end
> local i = 1
> for s in data:gmatch('[^|]+') do
> ngx.var["_v" .. i] = s
> i = i + 1
> end
> }
> alias /;
> try_files
> $_v2$uri
> /var/www/pub/$_v1/!$uri
> /var/www/pub/!$uri
> @;
> add_header Access-Control-Allow-Origin $_origin;
> expires 28d;
> }
> location dir: {
> alias /;
> index :none;
> autoindex on;
> }
> location file: {
> alias /;
> }
> location @ {
> fastcgi_param DOCUMENT_ROOT $_v2;
> fastcgi_param SCRIPT_FILENAME $_v3;
> fastcgi_param SCRIPT_NAME $fastcgi_script_name;
> fastcgi_param SERVER_PROTOCOL $server_protocol;
> fastcgi_param SERVER_ADDR $server_addr;
> fastcgi_param SERVER_PORT $server_port;
> fastcgi_param SERVER_NAME $host;
> fastcgi_param REMOTE_ADDR $remote_addr;
> fastcgi_param REMOTE_PORT $remote_port;
> fastcgi_param REQUEST_SCHEME $scheme;
> fastcgi_param REQUEST_METHOD $request_method;
> fastcgi_param REQUEST_URI $request_uri;
> fastcgi_param QUERY_STRING $query_string;
> fastcgi_param CONTENT_TYPE $content_type;
> fastcgi_param CONTENT_LENGTH $content_length;
> fastcgi_pass upstream;
> }
> }
> }
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?2,291674,291674#msg-291674
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 27 May 2021 14:55:24 -0400
> From: "Rai Mohammed" <nginx-forum at forum.nginx.org>
> To: nginx at nginx.org
> Subject: How to do a large buffer size > 64k uWSGI requests with Nginx
> proxy | uwsgi request is too big with nginx
> Message-ID:
> <
> c303563b562a6243138081c03cc4c7ff.NginxMailingListEnglish at forum.nginx.org>
>
> Content-Type: text/plain; charset=UTF-8
>
> How to do a large buffer size > 64k uWSGI requests with Nginx proxy
>
> Deployment stack :
> Odoo ERP 12
> Python 3.7.10 and Werkzeug 0.16.1 as backend
> Nginx proxy : 1.20.0
> uWSGI : 2.0.19.1
> OS : FreeBSD 13.0-RELEASE
>
> Nginx throw an alert from uwsgi of request is too big
> Alert : uwsgi request is too big: 81492, client: 10.29.79.250, server:
> odoo12ce-erp, request: "GET /web/webclient/..........."
>
> As you can see I increased the "uwsgi_buffer_size " in both uwsgi.ini and
> nginx.conf.
>
> Nginx config :
> `{
>
> # increase the size of the buffers to handle odoo data
> # Activate uwsgi_buffering
> uwsgi_buffering on;
> uwsgi_buffers 16 128k;
> uwsgi_buffer_size 128k;
> uwsgi_busy_buffers_size 256k;
> # uwsgi_max_temp_file_size with zero value disables buffering of
> responses to temporary files
> uwsgi_max_temp_file_size 0;
> uwsgi_temp_file_write_size 256k;
>
> uwsgi_read_timeout 900s;
> uwsgi_connect_timeout 900s;
> uwsgi_send_timeout 900s;
>
> }`
>
> uwsgi.ini config :
>
> `
>
> [uwsgi]
> strict = true
> pcre-jit = true
> #limit-as = 1024
> #never-swap = true
>
> pidfile = /var/run/odoo_erp/odoo12ce_uwsgi.pid
> # safe-pidfile = /var/run/odoo_erp/odoo12ce.pid
>
> # Enable REUSE_PORT flag on socket to allow multiple instances binding
> on the same address (BSD only).
> reuse-port = true
>
> # Testing with www or odoo12ce
> uid = odoo12ce
> gid = odoo12ce
>
> # To test and verification
> callable = application
> # To test and verification
> #module = odoo.service.wsgi_server:application
>
> # enable uwsgi master process
> master = true
> lazy = true
> lazy-apps=true
>
> # turn on memory usage report
> #memory-report=true
>
> enable-threads = true
> threads = 2
> thunder-lock = true
> so-keepalive = true
>
> buffer-size = 262144
> http-buffer-size = 262144
>
> response-headers-limit = 262144
> http-headers-timeout = 900
> # set max connections to 1024 in uWSGI
> listen = 1024
>
> so-send-timeout = 900
> socket-send-timeout = 900
> so-write-timeout = 900
> socket-write-timeout = 900
>
> http-timeout = 900
> socket-timeout = 900
>
> wsgi-accept-buffer = true
> wsgi-accept-buffers = true
> # clear environment on exit and Delete sockets during shutdown
> vacuum = true
> single-interpreter = true
>
> # Shutdown when receiving SIGTERM (default is respawn)
> die-on-term = true
> need-app = true
>
> # Disable built-in logging
> disable-logging = false
>
> # but log 4xx's and 5xx's anyway
> log-4xx = true
> log-5xx = true
>
> # full path to Odoo12ce project's root directory
> chdir = /odoo_erp/odoo12ce/odoo12ce_server
> #chdir2 = = /odoo_erp/odoo12ce/odoo12ce_server
>
> pythonpath = /odoo_erp/odoo12ce/odoo12ce_server
>
> # odoo12ce's wsgi file
> wsgi-file = /odoo_erp/odoo12ce/odoo12ce_server/setup/odoo12ce-uwsgi.py
>
> #emperor = /odoo_erp/odoo12ce/vassals
>
> uwsgi-socket = 127.0.0.1:8070
> uwsgi-socket = 127.0.0.1:8170
>
> # daemonize uwsgi and write messages into given log
> daemonize = /var/log/odoo_erp/odoo12ce/odoo12ce_uwsgi_emperor.log
>
> # Restart workers after this many requests
> max-requests = 2000
>
> # Restart workers after this many seconds
> max-worker-lifetime = 3600
>
> # Restart workers after this much resident memory
> reload-on-rss = 2048
>
> # How long to wait before forcefully killing workers
> worker-reload-mercy = 90
>
> # Maximum number of workers allowed (cpu * 2)
> processes = 8
>
> `
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?2,291675,291675#msg-291675
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 27 May 2021 22:26:29 +0300
> From: "Valentin V. Bartenev" <vbart at nginx.com>
> To: nginx at nginx.org
> Subject: Unit 1.24.0 release
> Message-ID: <4650105.31r3eYUQgx at vbart-laptop>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi,
>
> I'm glad to announce a new release of NGINX Unit.
>
> This one is full of shiny new features. But before I dive into the
> details,
> let me introduce our new developers without whom this release wouldn't be
> so
> feature-rich. Please, welcome Zhidao Hong (???) and Ois?n Canty.
>
> Zhidao has already been contributing to various nginx open-source projects
> for
> years as a community member, and I'm very excited to finally have him on
> board.
>
> Ois?n is a university student who's very interested in Unit; he joined our
> dev
> team as an intern and already shown solid coding skills, curiosity, and
> attention to details, which is so important to our project. Good job!
>
>
> Now, back to the features. I'd like to highlight the first of our
> improvements
> in serving static media assets.
>
> :: MIME Type Filtering ::
>
> Now, you can restrict file serving by MIME type:
>
> {
> "share": "/www/data",
> "types": [ "image/*", "video/*" ]
> }
>
> The configuration above allows only files with various video and image
> extensions, but all other requests will return status code 403.
>
> In particular, this goes well with the "fallback" option that performs
> another
> action if the "share" returns a 40x error:
>
> {
> "share": "/www/data",
> "types": [ "!application/x-httpd-php" ],
>
> "fallback": {
> "pass": "applications/php"
> }
> }
>
> Here, all requests to existing files other than ".php" will be served as
> static
> content while the rest will be passed to a PHP application.
>
> More examples and documentation snippets are available here:
>
> - https://unit.nginx.org/configuration/#mime-filtering
>
>
> :: Chrooting and Path Restrictions When Serving Files ::
>
> As we take security seriously, now Unit introduces the ability to chroot
> not only its application processes but also the static files it serves on
> a per-request basis. Additionally, you can restrict traversal of mounting
> points and symbolic link resolution:
>
> {
> "share": "/www/data/static/",
> "chroot": "/www/data/",
> "follow_symlinks": false,
> "traverse_mounts": false
> }
>
> See here for more information:
>
> - https://unit.nginx.org/configuration/#path-restrictions
>
> For details of Unit application process isolation abilities:
>
> - https://unit.nginx.org/configuration/#process-isolation
>
>
> Other notable features unrelated to static file serving:
>
> * Multiple WSGI/ASGI Python entry points per process
>
> It allows loading multiple modules or app entry points into a single
> Python
> process, choosing between them when handling requests with the full
> power of
> Unit's routes system.
>
> See here for Python's "targets" object description:
>
> - https://unit.nginx.org/configuration/#configuration-python-targets
>
> And here, more info about Unit's internal routing:
>
> - https://unit.nginx.org/configuration/#routes
>
>
> * Automatic overloading of "http" and "websocket" modules in Node.js
>
> Now you can run Node.js apps on Unit without touching their sources:
>
> - https://unit.nginx.org/configuration/#node-js
>
>
> * Applying OpenSSL configuration commands
>
> Finally, you can control various TLS settings via OpenSSL's generic
> configuration interface with all the dynamic power of Unit:
>
> - https://unit.nginx.org/configuration/#ssl-tls-configuration
>
>
> The full changelog for the release:
>
> Changes with Unit 1.24.0 27 May
> 2021
>
> *) Change: PHP added to the default MIME type list.
>
> *) Feature: arbitrary configuration of TLS connections via OpenSSL
> commands.
>
> *) Feature: the ability to limit static file serving by MIME types.
>
> *) Feature: support for chrooting, rejecting symlinks, and rejecting
> mount point traversal on a per-request basis when serving static
> files.
>
> *) Feature: a loader for automatically overriding the "http" and
> "websocket" modules in Node.js.
>
> *) Feature: multiple "targets" in Python applications.
>
> *) Feature: compatibility with Ruby 3.0.
>
> *) Bugfix: the router process could crash while closing a TLS
> connection.
>
> *) Bugfix: a segmentation fault might have occurred in the PHP module
> if
> fastcgi_finish_request() was used with the "auto_globals_jit" option
> enabled.
>
>
> That's all for today, but even more exciting features are poised for the
> upcoming releases:
>
> - statistics API
> - process control API
> - variables from regexp captures in the "match" object
> - simple request rewrites using variables
> - variables support in static file serving options
> - ability to override client IP from the X-Forwarded-For header
> - TLS sessions cache and tickets
>
> Also, please check our GitHub to follow the development and discuss new
> features:
>
> - https://github.com/nginx/unit
>
> Stay tuned!
>
> wbr, Valentin V. Bartenev
>
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 28 May 2021 02:53:53 +0300
> From: Maxim Dounin <mdounin at mdounin.ru>
> To: nginx at nginx.org
> Subject: Re: How to do a large buffer size > 64k uWSGI requests with
> Nginx proxy | uwsgi request is too big with nginx
> Message-ID: <YLAxEUEUyrvdUlQr at mdounin.ru>
> Content-Type: text/plain; charset=us-ascii
>
> Hello!
>
> On Thu, May 27, 2021 at 02:55:24PM -0400, Rai Mohammed wrote:
>
> > How to do a large buffer size > 64k uWSGI requests with Nginx proxy
> >
> > Deployment stack :
> > Odoo ERP 12
> > Python 3.7.10 and Werkzeug 0.16.1 as backend
> > Nginx proxy : 1.20.0
> > uWSGI : 2.0.19.1
> > OS : FreeBSD 13.0-RELEASE
> >
> > Nginx throw an alert from uwsgi of request is too big
> > Alert : uwsgi request is too big: 81492, client: 10.29.79.250, server:
> > odoo12ce-erp, request: "GET /web/webclient/..........."
> >
> > As you can see I increased the "uwsgi_buffer_size " in both uwsgi.ini and
> > nginx.conf.
>
> The uwsgi protocol uses 16-bit datasize field[1], and this limits
> maximum size of all headers in a request to uwsgi backends. The
> error message from nginx suggests you are hitting this limit.
> Unfortunately, using larger buffers won't help here.
>
> In most cases such a huge request headers indicate that there is a
> bug somewhere. For example, nginx by default limits total size of
> request headers to 32k (see [2]). Similar 64k limit also exists
> in FastCGI (though with protocol clearly defining how to provide
> additional data if needed, just not implemented in nginx), and the
> only case when it was questioned was due to a miscoded client (see
> [3]).
>
> If nevertheless such a huge request headers are intentional, the
> most simple solution probably would be to switch to a different
> protocol, such as HTTP.
>
> [1] https://uwsgi-docs.readthedocs.io/en/latest/Protocol.html
> [2] http://nginx.org/r/large_client_header_buffers
> [3] https://trac.nginx.org/nginx/ticket/239
>
> --
> Maxim Dounin
> http://mdounin.ru/
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 27 May 2021 21:59:13 -0400
> From: "Rai Mohammed" <nginx-forum at forum.nginx.org>
> To: nginx at nginx.org
> Subject: Re: How to do a large buffer size > 64k uWSGI requests with
> Nginx proxy | uwsgi request is too big with nginx
> Message-ID:
> <
> 06b5de642b1389c66bdbe8e193824603.NginxMailingListEnglish at forum.nginx.org>
>
> Content-Type: text/plain; charset=UTF-8
>
> Hello,
> Yes I have searched the request that generates this big size header, and
> it's a Get URI
> pulling all the features installed and requested by the user of the ERP.
>
> Before I integrate the uWSGI layer, the stack deployment with Nginx KTLS
> HTTP2 works perfectly and there's
> no problem of buffer sizing.
> The reason why I added the uWSGI layer, is for using the uwsgi-socket
> binary
> protocol, and it work fine and very fast
> decreasing the time load for the principal web page.
> So for now I have to switch to the http-socket protocol and configuring
> HTTP2 in uWSGI.
> I hope in the future Nginx will allow using the huge headers sizing.
>
> Thanks for your reply and clarifications.
>
> Posted at Nginx Forum:
> https://forum.nginx.org/read.php?2,291675,291680#msg-291680
>
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 28 May 2021 09:00:00 +0100
> From: Francis Daly <francis at daoine.org>
> To: nginx at nginx.org
> Subject: Re: Help: Using Nginx Reverse Proxy bypass traffic in to a
> application running in a container
> Message-ID: <20210528080000.GC11167 at daoine.org>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, May 25, 2021 at 09:47:47PM +0530, Amila Gunathilaka wrote:
>
> Hi there,
>
> > I'm sorry for taking time to reply to this, you were so keen about my
> > problem. Thank you.
>
> No worries at all -- the mailing list is not an immediate-response medium.
>
> > Actually my problem was when sending *response *to the load balancer from
> > the nginx ( not the request, it should be corrected as the *response *in
> my
> > previous email).
> > Such as my external load balancer is always doing a health check for my
> > nginx port (80) , below is the *response *message in the
> > /var/log/nginx/access.log against the health check request coming from
> > the external-loadbalancer.
>
> As I understand it, the load balancer is making the request "OPTIONS /"
> to nginx, and nginx is responding with a http 405, and you don't want
> nginx to do that.
>
> What response do you want nginx to give to the request?
>
> Your config make it look like nginx is told to proxy_pass the OPTIONS
> request to your port 9091 server, so I presume that your port 9091 server
> is responding 405 to the OPTIONS request and nginx is passing the response
> from the 9091-upstream to the load-balancer client.
>
> Your port 9091 logs or traffic analysis should show that that is the case.
>
> If is the case, you *could* fix it by telling your 9091-upstream to respond
> how you want it to to the "OPTIONS /" request (using its config); or
> you could configure nginx to intercept the request and handle it itself,
> without proxy_pass'ing it
>
>
> The first case would mean that the "health check" is actually testing
> the full nginx-to-upstream chain; the second would have it only testing
> that nginx is responding.
>
> If you decide that you want nginx to handle this request itself, and to
> respond with a http 204, you could add something like
>
> if ($request_method = "OPTIONS") { return 204; }
>
> inside the "location /" block.
>
> (Strictly: that would tell nginx to handle all "OPTIONS /anything"
> requests, not just "OPTIONS /".)
>
> You would not need the error_page directives that you show.
>
>
> You could instead add a new "location = /" block, and do the OPTIONS
> check there; but you would probably also have to duplicate the three
> other lines from the "location /" block -- sometimes people prefer
> "tidy-looking" configuration over "correctness and probable machine
> efficiency". Pick which you like; if you do not measure a difference,
> there is not a difference that you care about.
>
> That is, you want either one location:
>
> > server {
> > listen 80;
> > server_name 172.25.234.105;
>
> > location / {
>
> if ($request_method = "OPTIONS") { return 204; }
>
> > proxy_pass http://127.0.0.1:9091;
> > auth_basic "PROMETHEUS PUSHGATEWAY Login Area";
> > auth_basic_user_file /etc/nginx/.htpasswd;
> > }
> > }
>
> or two locations:
>
> location = / {
> if ($request_method = "OPTIONS") { return 204; }
> proxy_pass http://127.0.0.1:9091;
> auth_basic "PROMETHEUS PUSHGATEWAY Login Area";
> auth_basic_user_file /etc/nginx/.htpasswd;
> }
>
> location / {
> proxy_pass http://127.0.0.1:9091;
> auth_basic "PROMETHEUS PUSHGATEWAY Login Area";
> auth_basic_user_file /etc/nginx/.htpasswd;
> }
>
> (and, if you use the two, you could potentially move the "auth_basic"
> and "auth_basic_user_file" outside the "location", to be directly within
> "server"; that does depend on what else is in your config file.)
>
> If you want something else in the response to the OPTIONS request,
> you can change the "return" response code, or "add_header" and the like.
>
> Good luck with it,
>
> f
> --
> Francis Daly francis at daoine.org
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
> ------------------------------
>
> End of nginx Digest, Vol 139, Issue 28
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20210529/398430ff/attachment-0001.htm>
More information about the nginx
mailing list