<div dir="ltr">Hi Francis, <br><br>Hope you are doing good ?  Thanks for your quick responses for my emails again.  I have 02 questions  for you today,  I will brief it down for your ease.<br><br><b>quiz (1.)  : </b> Yes I understand some of my clients requests don't have user/name password in their requests and that's why it gives 401 in the access.log file.  <br>       But also for me when I browse the site in my internal network browser <a href="http://172.25.234.105/metrics">http://172.25.234.105/metrics</a>  its pop up the user name and password enter window and directs me successfully to the /metrics page and I can view contents.  But when I tail the /var.log/nginx/error.log file for a moment and even after I log in by type username and password the error log gives below error message unless the login is successful.  <br><br><i>tail -f 

/var.log/nginx/error.log output<br></i><br>2021/06/01 11:25:26 [crit] 2379013#2379013: *57800 open() "/var/lib/nginx/proxy/4/79/0000002794" failed (<b>13: Permission denied</b>) while reading upstream, client: 172.20.0.201, server: 172.25.234.105, request: "GET /metrics HTTP/1.1", upstream: "<a href="http://127.0.0.1:9091/metrics">http://127.0.0.1:9091/metrics</a>", host: "172.25.234.105"<div><br><br>So my first quiz is why it gives a Permission denied message for my request through the browser even after I enter credentials and I can view /metrics page contents.   <br><br>(note*  -  in my nginx /etc/nginx/.htpasswd file I have the password as encrypted but I enter the unencrypted password.  I hope that's not an issue since the login is successful.)<br><br><br><b>quiz (2.) : </b> My second question for you is if I want to redirect the url, such as when I enter 

<a href="http://172.25.234.105:80">http://172.25.234.105:80</a>  I want it to automatically redirect it to the page   <a href="http://172.25.234.105/metrics">http://172.25.234.105/metrics</a>. How could I achieve that via nginx ? <br><br><br>Thanks for your effortless help for my questions Mr Francis ( even though I don't know your real name, lol)   ;  Appreciate a lot. <br><br><br>Amila<br>Devops Engineer<br>RHCSA, CKA, AWS</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 1, 2021 at 5:30 PM <<a href="mailto:nginx-request@nginx.org">nginx-request@nginx.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Send nginx mailing list submissions to<br>
        <a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a><br>
or, via email, send a message with subject or body 'help' to<br>
        <a href="mailto:nginx-request@nginx.org" target="_blank">nginx-request@nginx.org</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:nginx-owner@nginx.org" target="_blank">nginx-owner@nginx.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of nginx digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
   1. Re: Help: Using Nginx Reverse Proxy bypass traffic in to a<br>
      application running in a container (Francis Daly)<br>
   2. Re: Help: Using Nginx Reverse Proxy bypass traffic in to a<br>
      application running in a container (Francis Daly)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Tue, 1 Jun 2021 07:54:26 +0100<br>
From: Francis Daly <<a href="mailto:francis@daoine.org" target="_blank">francis@daoine.org</a>><br>
To: <a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a><br>
Subject: Re: Help: Using Nginx Reverse Proxy bypass traffic in to a<br>
        application running in a container<br>
Message-ID: <<a href="mailto:20210601065426.GH11167@daoine.org" target="_blank">20210601065426.GH11167@daoine.org</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
On Sat, May 29, 2021 at 07:11:38PM +0530, Amila Gunathilaka wrote:<br>
<br>
Hi there,<br>
<br>
It sounds like you have the main part solved by changing the "health<br>
check" request to be one that your port-9091 upstream is able to handle,<br>
which is good.<br>
<br>
> >As I understand it, the load balancer is making the request "OPTIONS /"<br>
> >to nginx, and nginx is responding with a http 405, and you don't want<br>
> >nginx to do that.<br>
> <br>
> >What response do you want nginx to give to the request?<br>
> <br>
> Yes you are absolutely right I wanted nginx to stop that 405 response and<br>
> give the success response 200 or even 401 which I can confirm my proxy pass<br>
> and basic auth is working.<br>
<br>
After you decide what response you want nginx to give to the request,<br>
you can configure nginx to do that.<br>
<br>
In this case, if you want nginx to give a 401 if no valid credentials are<br>
provided, then you want something like auth_basic; if you want nginx to<br>
give a 200 if no valid credentials are provided, then you must not have<br>
something like auth_basic.<br>
<br>
> Also I think that 405 response is coming *from nginx itself *to the<br>
> external load balancer because external load balancer directly<br>
> communicating with the nginx (80) and also my upstream server (9091 port<br>
> server)  is not a webapp it's just a binary file running inside docker<br>
> container.<br>
<br>
>From nginx's point of view, it does not matter what the upstream/back-end<br>
service is; it matters that it responds correctly to http requests.<br>
<br>
When I use a similar configuration to yours, I see the OPTIONS request<br>
being sent to the upstream and getting a 405 from there.<br>
<br>
> Anyway I thought to fix the OPTIONS method fix on the external load<br>
> balancer itself ,  and I logged in to my external load balancer configs<br>
> page and I changed the  HTTP health checks using OPTIONS into *GET *<br>
> method.<br>
> ANd yeah now 405 error gone.  But now I'm getting 401 responses , which<br>
> should be the correct response since I'm using a basic auth in my<br>
> nginx.conf file.  Below is my nginx.conf  FYI<br>
<br>
Good stuff.<br>
<br>
This says that, for any request starting with /metrics, nginx should<br>
check for valid credentials or return 401; and then pass the request to<br>
the upstream and return whatever it returns.<br>
<br>
>         location /metrics {<br>
>              proxy_pass <a href="http://127.0.0.1:9091/metrics" rel="noreferrer" target="_blank">http://127.0.0.1:9091/metrics</a>;<br>
<br>
One small thing: because the end of the "proxy_pass" directive is<br>
exactly equal to the full "location" value, you could omit it from the<br>
"proxy_pass"; that is, you could instead use<br>
<br>
        proxy_pass <a href="http://127.0.0.1:9091" rel="noreferrer" target="_blank">http://127.0.0.1:9091</a>;<br>
<br>
but when what you have works, it works.<br>
<br>
Cheers,<br>
<br>
        f<br>
-- <br>
Francis Daly        <a href="mailto:francis@daoine.org" target="_blank">francis@daoine.org</a><br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Tue, 1 Jun 2021 08:06:33 +0100<br>
From: Francis Daly <<a href="mailto:francis@daoine.org" target="_blank">francis@daoine.org</a>><br>
To: <a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a><br>
Subject: Re: Help: Using Nginx Reverse Proxy bypass traffic in to a<br>
        application running in a container<br>
Message-ID: <<a href="mailto:20210601070633.GI11167@daoine.org" target="_blank">20210601070633.GI11167@daoine.org</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
On Sat, May 29, 2021 at 07:46:40PM +0530, Amila Gunathilaka wrote:<br>
<br>
Hi there,<br>
<br>
> My concern is why nginx still gives 401 responses *unless *my nginx.conf<br>
> has a basic authentication user name and password file in the<br>
> location /etc/nginx/.htpasswd.<br>
> <br>
> It says still not authenticate my external client POST requests yet ?   Any<br>
> thoughts?<br>
<br>
I'm not sure I understand your question.<br>
<br>
"auth_basic" says "for each each request to nginx, if the user/password in<br>
the request does not match something in the file, nginx should return 401"<br>
<br>
If you want nginx to do authentication checks, you want auth_basic and<br>
auth_basic_user_file, If you do not want nginx to do authentication checks,<br>
you do not want auth_basic.<br>
<br>
<a href="http://nginx.org/r/auth_basic" rel="noreferrer" target="_blank">http://nginx.org/r/auth_basic</a><br>
<br>
(You can use "auth_basic off;" if you want one location{} not to use<br>
auth_basic that would be inherited from a surrounding context.)<br>
<br>
If that does not tell you what you want, could you explain again, please?<br>
<br>
Thanks,<br>
<br>
        f<br>
-- <br>
Francis Daly        <a href="mailto:francis@daoine.org" target="_blank">francis@daoine.org</a><br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org" target="_blank">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a><br>
<br>
------------------------------<br>
<br>
End of nginx Digest, Vol 140, Issue 1<br>
*************************************<br>
</blockquote></div>