1

I'm trying to get Nginx to return a simple webpage, but always with an http status code of 403. For some reason, I just can't get it to work. I have two files in /var/www/html/:

  • index.html
  • photo.jpg

index.html displays some text along with photo.jpg

Here is my Nginx config:

server { listen 80 default_server; listen [::]:80 default_server; root /var/www/html; index index.html index.htm index.nginx-debian.html; server_name _; location / { return 403; } error_page 404 /index.html; error_page 403 /index.html; location = /index.html { allow all; } location = /photo.jpg { allow all; } }

With this config as-is, both index.html and photo.jpg are displayed with a status of 200. If I remove the location blocks for those two files, neither are displayed, but they have a status of 403. My question is: How can I display the html file, along with the image, but just return a status of 403? I feel like I'm missing something simple.

Improve this question
3
  • Why are you trying to do this? If you send a 403 the browser is not required to display the response body, and some browsers do not do so by default (such as IE). Commented Oct 18, 2016 at 16:57
  • This Nginx server is running along side a squid proxy. When a client PC attempts to access a URL that's not on the proxy's whitelist, it's redirected to this page hosted on Nginx. We have a Nagios script that makes sure the proxy is functioning by attempting to access a blocked URL through this proxy. The script checks the status of the request--200 means the proxy allowed the URL, and 403 (in this case) means the proxy redirected the client to our Nginx server . I don't have to use 403, I just need Nginx to reliably return something other than 200 along with the webpage we want to display. Commented Oct 18, 2016 at 17:45
  • In theory, nowdays, it should be possible by return 403 <url>; or return 403 "some text with newline at the end";. nginx.org/en/docs/http/ngx_http_rewrite_module.html#return But I haven't tested it personally. Commented Apr 16 at 14:23

1 Answer 1

Reset to default
8

Your location / {}, containing a return 403; matches first. You should move it below two others.

Happy leg shooting !

Improve this answer
5
  • To avoid said leg shooting, I decided to back up and re-configure things a different way that doesn't rely on the HTTP status codes. I haven't tested your suggestion as it's no longer applicable, but I appreciate it. Commented Oct 19, 2016 at 15:17
  • I don’t have enough rep to downvote, but that’s wrong. The order in which you define your blocks doesn’t matter; the best match always wins. In OP’s case, changing the order doesn’t change anything to their issue. Commented Jul 21, 2023 at 6:41
  • Looks like someone won't get his rep any time soon. And that's perfect. Commented Jul 22, 2023 at 8:46
  • drookie, you actually wrong and your answer is wrong(besides being impolite). Order doesn't matter. RTFM nginx.org/en/docs/http/ngx_http_core_module.html#location Commented Apr 16 at 13:09
  • 1
    Small correction. Order for prefix matching locations doesn't matter. It does matter for regex matching. But we don't see them in Q. Commented Apr 16 at 14:20

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.