Forum: NGINX forced 404 without a location display ?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
3fc448a0368821b51a9f7e2781a8b7a6?d=identicon&s=25 Jonathan Vanasco (Guest)
on 2016-07-11 21:26
(Received via mailing list)
I have some servers where I use an old method of gating a path by using
a file check.

this allows staff to turn off certain locations during
migrations/updates without having root privileges (needed to restart
nginx)

an issue I noticed this method now (perhaps always) shows the name of
the location on the default 404 template [the response that nginx
generates via code, not a template on the fs]

Does anyone know how to disable showing the location without defining a
custom template on the filesystem?  or perhaps someone can think of a
better way to accomplish my goals?



location /paths/to/ {
    if (!-f /etc/nginx/_flags/is_running) {
        rewrite ^.*$ @is_running break;
    }
}
location = @is_running {
    return 404;
}

=======
that generates this


  <html>
   <head>
    <title>404 Not Found</title>
   </head>
   <body>
    <h1>404 Not Found</h1>
    The resource could not be found.<br/><br/>
  /@is_running


   </body>
  </html>
4ec56486d2ca9d8e9522567fea8c9d40?d=identicon&s=25 Oleg A. Mamontov (Guest)
on 2016-07-11 22:25
(Received via mailing list)
On Mon, Jul 11, 2016 at 03:26:30PM -0400, Jonathan Vanasco wrote:
> location /paths/to/ {
>
>
>    </body>
>   </html>

=============================================
location /paths/to/ {
    if ( !-f /etc/nginx/_flags/is_running ) {
        rewrite ^ /is_running last;
    }
}
location = /is_running {
    internal;
    return 404 'nothing\n';
}
=============================================

Does it work for you?

--
Cheers,
Oleg A. Mamontov

mailto: oleg@mamontov.net

skype:  lonerr11
cell:   +7 (903) 798-1352
A8108a0961c6087c43cda32c8616dcba?d=identicon&s=25 Maxim Dounin (Guest)
on 2016-07-11 22:28
(Received via mailing list)
Hello!

On Mon, Jul 11, 2016 at 03:26:30PM -0400, Jonathan Vanasco wrote:

>
> }
>     <title>404 Not Found</title>
>    </head>
>    <body>
>     <h1>404 Not Found</h1>
>     The resource could not be found.<br/><br/>
>   /@is_running
>
>
>    </body>
>   </html>

This is not something nginx generates.
An nginx-generated error will look like:

<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.11.3</center>
</body>
</html>

No location information is added by nginx to error pages, and
never was.  You are probably using something with 3rd party
patches.  An obvious fix is to switch to using vanilla nginx
instead, it can be downloaded here:

http://nginx.org/en/download.html

--
Maxim Dounin
http://nginx.org/
3fc448a0368821b51a9f7e2781a8b7a6?d=identicon&s=25 Jonathan Vanasco (Guest)
on 2016-07-13 00:46
(Received via mailing list)
On Jul 11, 2016, at 4:27 PM, Maxim Dounin wrote:
> No location information is added by nginx to error pages, and
> never was.  You are probably using something with 3rd party
> patches.  An obvious fix is to switch to using vanilla nginx
> instead, it can be downloaded here:

On Jul 11, 2016, at 4:25 PM, Oleg A. Mamontov wrote:

> =============================================
Thanks to you both!

I spent way more time than I should tracking the issue.  I finally
figured it out.  Details below:

1. I am using a non-standard nginx -- I run openresty.  I thought this
might have been the issue so started creating test-cases to pin down,
and running against all the nginx & openresty versions. I could not
consistently get this to repeat.

2. The first part of the problem is that I had `break` on my rewrite,
instead of `last`.

3. The second part of my problem, and this is where the confusion
happened -- a proxypass was involved

Using `last`:
  what i wanted happened

Using `break`
  the rewrite to `/is_running` got passed to the proxypass; the
application was creating the error message
  the app's error message template was very similar to nginx -- and that
threw me off
  i only figured this out, because nginx served an error when the
application was taken offline during an update
This topic is locked and can not be replied to.