The question is, how do I use the foreach construct in the nginx
configuration file?
> I am using openresty
> nginx -version
> nginx version: openresty/1.21.4.1
> This fails:
>
>
>
>> foreach $domain in $server_name {
>>>
>> ssl_certificate /etc/letsencrypt/live/$domain/fullchain.pem;
>> ssl_certificate_key /etc/letsencrypt/live/$domain/privkey.pem;
>> }
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230221/4301fa4d/attachment.htm>
Hi there,
On Tue, Feb 21, 2023 at 02:25:23AM -0500, Saint Michael wrote:
> The question is, how do I use the foreach construct in the nginx
> configuration file?
There's no foreach directive in the nginx directives list, [1],
please take a look.
That's probably something openresty related, so it's better to
ask such a question in an appropriate mailing list.
Thank you.
References
1. https://nginx.org/en/docs/dirindex.html
--
Sergey A. Osokin
>
> I have a location
root /static/duc/Digital_Universal_Currency;
# ... other directives ...
location / {
try_files /index.html =404;
}
you my see it directly
https://securedigitalcheck.com
The images don't work. No browser can see them.
if I download them directly with wget, they download, same size, but in
Windows they do not open with paint or with Chrome, the error message says
that they are "format unknown".
but if I download the image via SCP, directly, there is nothing wrong with
them.
so what is ningx doing?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230222/fdd77ae3/attachment.htm>
I think my fundamental misunderstanding was that a `location` block in
the nginx configuration always maps to a directory (folder) in the
file system. The root just identifies the default file. (this also
means that the browser can then always look around for other files in
this directory, though they may be kept unreadable for security.)
I was trying to define one specific URL to map to one specific file in
the file system. Is this possible? That is, is there a way to map one
specific URL to one specific file?
/iaw
On Mon, Feb 20, 2023 at 4:08 AM Francis Daly <francis at daoine.org> wrote:
>
> On Sun, Feb 19, 2023 at 05:49:48PM -0800, Ivo Welch wrote:
>
> Hi there,
>
> > thank you, F. I created a completely new ubuntu VM, with a completely
> > vanilla configuration and only this one extra location statement at
> > http://164.67.176.22/ , describing the nginx configuration and
> > referencing its /wth, and it's not working :-( .
>
> For the convenience of future searchers, it would be better to include
> the content at that url in the mail directly.
>
> In this particular case, I suspect that the key line is
>
> > try /wth, which nginx should resolve to
> > /var/www/fcgi-bin/wth-root.html. However, this causes a 404 error.
>
> When you make the request to /wth and get the 404 response, what is
> written in the nginx error log? That will tell you what nginx thought
> that nginx was doing; if that does not match what you thought that nginx
> should be doing, that might point at the problem.
>
> I suspect that the issue is a misunderstanding of what "root" does --
> http://nginx.org/r/root. That content also includes a link to "alias",
> which might be what you want, depending on what you want to have happen.
>
> Good luck with it,
>
> f
> --
> Francis Daly francis at daoine.org
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx
Hi Ivo,
On Wed, Feb 22, 2023 at 09:44:42AM -0800, Ivo Welch wrote:
> I think my fundamental misunderstanding was that a `location` block in
> the nginx configuration always maps to a directory (folder) in the
> file system. The root just identifies the default file. (this also
> means that the browser can then always look around for other files in
> this directory, though they may be kept unreadable for security.)
The root directive's description, [1], provides details how the directive
works. Would you mind to provide more details in case the documentation
is unclear in that place, thank you.
> I was trying to define one specific URL to map to one specific file in
> the file system. Is this possible? That is, is there a way to map one
> specific URL to one specific file?
The alias directive [2] may help in some cases, so please take a look on
that directive and report back how does that work for you.
Thank you.
References
1. https://nginx.org/en/docs/http/ngx_http_core_module.html#root
2. https://nginx.org/en/docs/http/ngx_http_core_module.html#alias
--
Sergey A. Osokin
I found the solution here
https://laracasts.com/discuss/channels/general-discussion/homestead-nginx-serving-wrong-images-and-only-cut-in-the-middle
On Wed, Feb 22, 2023 at 10:57 AM Saint Michael <venefax at gmail.com> wrote:
> I have a location
>
> root /static/duc/Digital_Universal_Currency;
> # ... other directives ...
> location / {
>
> try_files /index.html =404;
> }
> you my see it directly
> https://securedigitalcheck.com
> The images don't work. No browser can see them.
> if I download them directly with wget, they download, same size, but in
> Windows they do not open with paint or with Chrome, the error message says
> that they are "format unknown".
> but if I download the image via SCP, directly, there is nothing wrong with
> them.
> so what is ningx doing?
>
>
>
>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230222/70be5445/attachment.htm>
I wonder if Nginx will ever fix this issue. It's a clear bug in the
product. I wasted two days of sleep on this issue.
On Wed, Feb 22, 2023 at 2:03 PM Saint Michael <venefax at gmail.com> wrote:
> I found the solution here
>
> https://laracasts.com/discuss/channels/general-discussion/homestead-nginx-serving-wrong-images-and-only-cut-in-the-middle
>
> On Wed, Feb 22, 2023 at 10:57 AM Saint Michael <venefax at gmail.com> wrote:
>
>> I have a location
>>
>> root /static/duc/Digital_Universal_Currency;
>> # ... other directives ...
>> location / {
>>
>> try_files /index.html =404;
>> }
>> you my see it directly
>> https://securedigitalcheck.com
>> The images don't work. No browser can see them.
>> if I download them directly with wget, they download, same size, but in
>> Windows they do not open with paint or with Chrome, the error message says
>> that they are "format unknown".
>> but if I download the image via SCP, directly, there is nothing wrong
>> with them.
>> so what is ningx doing?
>>
>>
>>
>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230222/fb3b9c3d/attachment-0001.htm>
On Wed, Feb 22, 2023 at 02:05:21PM -0500, Saint Michael wrote:
> I wonder if Nginx will ever fix this issue. It's a clear bug in the
> product. I wasted two days of sleep on this issue.
>From your previous email you've reported you've found a solution, so
that seems like not a bug and probably a misconfiguration on your
side or misunderstading of the official documentation.
However, in case you want to fill that as a bug, please use the
following URL, [1] , to submit a bug report with full descrpition
of your case.
Thank you.
1. https://trac.nginx.org/nginx/
--
Sergey A. Osokin
It's not a misconfiguration, is a huge bug.
A wasted two days of sleep for something that is 100% a bug.
Please read here:
https://laracasts.com/discuss/channels/general-discussion/homestead-nginx-serving-wrong-images-and-only-cut-in-the-middle
He mentions the same exact problem and also he points to
https://tech.blog.aknin.name/2011/11/04/nginxgzip-module-might-silently-corrupt-data-upon-backend-failure/
where the author says that Niginx will not fix it.
So he already tried he was rebuffed.
On Wed, Feb 22, 2023 at 2:32 PM Sergey A. Osokin <osa at freebsd.org.ru> wrote:
> On Wed, Feb 22, 2023 at 02:05:21PM -0500, Saint Michael wrote:
> > I wonder if Nginx will ever fix this issue. It's a clear bug in the
> > product. I wasted two days of sleep on this issue.
>
> From your previous email you've reported you've found a solution, so
> that seems like not a bug and probably a misconfiguration on your
> side or misunderstading of the official documentation.
>
> However, in case you want to fill that as a bug, please use the
> following URL, [1] , to submit a bug report with full descrpition
> of your case.
>
> Thank you.
>
> 1. https://trac.nginx.org/nginx/
>
> --
> Sergey A. Osokin
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230222/86fa9130/attachment.htm>
On Wed, Feb 22, 2023 at 09:44:42AM -0800, Ivo Welch wrote:
Hi there,
> I think my fundamental misunderstanding was that a `location` block in
> the nginx configuration always maps to a directory (folder) in the
> file system.
Yes, that's a misunderstanding.
The details at http://nginx.org/r/location might help clarify; but they
may be too terse for this.
> The root just identifies the default file.
That's a misunderstanding too. http://nginx.org/r/root for details.
> (this also
> means that the browser can then always look around for other files in
> this directory, though they may be kept unreadable for security.)
I'm not sure how that relates to the previous lines. Yes, the browser
can request any url. The server can choose how to respond to each request.
> I was trying to define one specific URL to map to one specific file in
> the file system. Is this possible? That is, is there a way to map one
> specific URL to one specific file?
location = /this-url { alias /var/www/that-file.txt; }
Cheers,
f
--
Francis Daly francis at daoine.org
Hello!
On Wed, Feb 22, 2023 at 02:46:29PM -0500, Saint Michael wrote:
> It's not a misconfiguration, is a huge bug.
> A wasted two days of sleep for something that is 100% a bug.
> Please read here:
> https://laracasts.com/discuss/channels/general-discussion/homestead-nginx-serving-wrong-images-and-only-cut-in-the-middle
> He mentions the same exact problem and also he points to
> https://tech.blog.aknin.name/2011/11/04/nginxgzip-module-might-silently-corrupt-data-upon-backend-failure/
> where the author says that Niginx will not fix it.
> So he already tried he was rebuffed.
The fun fact is that the referenced article doesn't state "will
not fix", but rather "not a top priority". Further, proper error
propagation is available in nginx for about 10 years now, since
2013 (http://hg.nginx.org/nginx/rev/d3eab5e2df5f, nginx 1.5.3).
Quoting CHANGES:
*) Change: now after receiving an incomplete response from a backend
server nginx tries to send an available part of the response to a
client, and then closes client connection.
As long as nginx have an information about an error, it will
preserve this information and propagate it to the client.
Also note that it is only expected to make a difference if you are
using nginx as a proxy, not to directly serve files. And only in
case of errors. That is, if you are seeing the behaviour
described, it might be a good idea to focus on the errors in the
first place.
I don't think it's anyhow related though, as switching gzip off
and back on, as seems to be "the fix" described in the first link,
is not going to help with anything. The important part is likely
"restarted the server", so I would rather assume that "the server"
(not sure if it refers to nginx or the whole server) was using an
incorrect configuration and/or was out of some resources, and
restart fixed it.
Summing the above, if you want to find out what goes wrong in your
case - you may want to provide more details. If you don't, nobody
will be able to do it, unfortunately.
The most basic thing I would recommend in the first place is to
look into nginx error log, it is likely to contain important
information if something goes wrong.
--
Maxim Dounin
http://mdounin.ru/
a) The error does not have a single line.
b) restarting does not fix it
c) my nginx is no acting as proxy
d) it happened twice and both times I fixed it by turning gzip off,
restarting, and back on.
e) I also noticed that I requested the image file with wget, get a full
HTML file for the whole document, but named as if it were the image file.
wget https://x3x.us/index_files/image001.jpg
but `stat image001.jpg' showed it was the entire text HTML file.
http {
client_max_body_size 1500M;
include mime.types;
# default_type application/octet-stream;
#log_format main '$remote_addr - $remote_user [$time_local]
"$request" '
# '$status $body_bytes_sent "$http_referer" '
# '"$http_user_agent" "$http_x_forwarded_for"';
#access_log logs/access.log main;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
gzip on;
gzip_vary on;
gzip_min_length 10240;
gzip_proxied expired no-cache no-store private auth;
gzip_types text/plain text/css text/xml text/javascript
application/x-javascript application/xml;
gzip_disable "MSIE [1-6]\.";
#keepalive_timeout 0;
keepalive_timeout 65;
types_hash_max_size 2048;
proxy_headers_hash_max_size 1024;
proxy_headers_hash_bucket_size 128;
#gzip on;
# error_log /var/log/nginx/error.log debug;
error_log /var/log/nginx/error.log error;
error_log /var/log/nginx/error.log crit;
access_log /var/log/nginx/access.log;
server {
add_header Strict-Transport-Security "max-age=31536000;
includeSubDomains" always;
default_type 'text/html; charset=UTF-8';
listen 208.78.161.6:80;
server_name x3x.us;
# Redirect all domains to https://x3x.us
if ($scheme != "https") {
return 301 https://x3x.us$request_uri;
}
}
server {
add_header Strict-Transport-Security "max-age=31536000;
includeSubDomains" always;
default_type 'text/html; charset=UTF-8';
listen 208.78.161.6:443 ssl;
server_name x3x.us;
ssl_certificate /etc/letsencrypt/live/x3x.us/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/x3x.us/privkey.pem;
root /static/duc/;
location / {
try_files $uri $uri/ /index.html;
}
} #server
} #http
On Wed, Feb 22, 2023 at 7:17 PM Maxim Dounin <mdounin at mdounin.ru> wrote:
> Hello!
>
> On Wed, Feb 22, 2023 at 02:46:29PM -0500, Saint Michael wrote:
>
> > It's not a misconfiguration, is a huge bug.
> > A wasted two days of sleep for something that is 100% a bug.
> > Please read here:
> >
> https://laracasts.com/discuss/channels/general-discussion/homestead-nginx-serving-wrong-images-and-only-cut-in-the-middle
> > He mentions the same exact problem and also he points to
> >
> https://tech.blog.aknin.name/2011/11/04/nginxgzip-module-might-silently-corrupt-data-upon-backend-failure/
> > where the author says that Niginx will not fix it.
> > So he already tried he was rebuffed.
>
> The fun fact is that the referenced article doesn't state "will
> not fix", but rather "not a top priority". Further, proper error
> propagation is available in nginx for about 10 years now, since
> 2013 (http://hg.nginx.org/nginx/rev/d3eab5e2df5f, nginx 1.5.3).
> Quoting CHANGES:
>
> *) Change: now after receiving an incomplete response from a backend
> server nginx tries to send an available part of the response to a
> client, and then closes client connection.
>
> As long as nginx have an information about an error, it will
> preserve this information and propagate it to the client.
>
> Also note that it is only expected to make a difference if you are
> using nginx as a proxy, not to directly serve files. And only in
> case of errors. That is, if you are seeing the behaviour
> described, it might be a good idea to focus on the errors in the
> first place.
>
> I don't think it's anyhow related though, as switching gzip off
> and back on, as seems to be "the fix" described in the first link,
> is not going to help with anything. The important part is likely
> "restarted the server", so I would rather assume that "the server"
> (not sure if it refers to nginx or the whole server) was using an
> incorrect configuration and/or was out of some resources, and
> restart fixed it.
>
> Summing the above, if you want to find out what goes wrong in your
> case - you may want to provide more details. If you don't, nobody
> will be able to do it, unfortunately.
>
> The most basic thing I would recommend in the first place is to
> look into nginx error log, it is likely to contain important
> information if something goes wrong.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230222/45e0aaaa/attachment.htm>
Hello!
On Wed, Feb 22, 2023 at 07:35:54PM -0500, Saint Michael wrote:
> a) The error does not have a single line.
> b) restarting does not fix it
> c) my nginx is no acting as proxy
So it's certainly unrelated to the article about proxying and
error propagation you've previously linked.
> d) it happened twice and both times I fixed it by turning gzip off,
> restarting, and back on.
> e) I also noticed that I requested the image file with wget, get a full
> HTML file for the whole document, but named as if it were the image file.
>
> wget https://x3x.us/index_files/image001.jpg
> but `stat image001.jpg' showed it was the entire text HTML file.
Your configuration contains:
try_files $uri $uri/ /index.html;
so returning "/index.html" for all non-existing files is what
nginx is configured to do.
Are you sure the file you are requesting actually exists? Is the
file system with these files local, or it's something distributed
and/or some network filesystem? Are files static, or generated
and/or synced from somewhere?
You may want to try removing the "try_files" directive, so nginx
will be able to properly respond with 404 on non-existing files,
and will log errors with details about attempts to request them.
Such errors will look like:
2023/02/23 05:16:25 [error] 80125#100117: *1 open() "/path/to/file" failed (2: No such file or directory), client: ...
This should help to identify exact files being requested, so
you'll be able to check them manually, as will contain exact error
code, so it will be possible to identify various permission
issues.
Hope this helps.
--
Maxim Dounin
http://mdounin.ru/
how would this line look?
try_files $uri $uri/ /index.html;
and how do set I the error log to the max level for this particular server
{}?
I am not getting any errors in /var/log/nginx/error.log
On Wed, Feb 22, 2023 at 9:28 PM Maxim Dounin <mdounin at mdounin.ru> wrote:
> Hello!
>
> On Wed, Feb 22, 2023 at 07:35:54PM -0500, Saint Michael wrote:
>
> > a) The error does not have a single line.
> > b) restarting does not fix it
> > c) my nginx is no acting as proxy
>
> So it's certainly unrelated to the article about proxying and
> error propagation you've previously linked.
>
> > d) it happened twice and both times I fixed it by turning gzip off,
> > restarting, and back on.
> > e) I also noticed that I requested the image file with wget, get a full
> > HTML file for the whole document, but named as if it were the image file.
> >
> > wget https://x3x.us/index_files/image001.jpg
> > but `stat image001.jpg' showed it was the entire text HTML file.
>
> Your configuration contains:
>
> try_files $uri $uri/ /index.html;
>
> so returning "/index.html" for all non-existing files is what
> nginx is configured to do.
>
> Are you sure the file you are requesting actually exists? Is the
> file system with these files local, or it's something distributed
> and/or some network filesystem? Are files static, or generated
> and/or synced from somewhere?
>
> You may want to try removing the "try_files" directive, so nginx
> will be able to properly respond with 404 on non-existing files,
> and will log errors with details about attempts to request them.
> Such errors will look like:
>
> 2023/02/23 05:16:25 [error] 80125#100117: *1 open() "/path/to/file" failed
> (2: No such file or directory), client: ...
>
> This should help to identify exact files being requested, so
> you'll be able to check them manually, as will contain exact error
> code, so it will be possible to identify various permission
> issues.
>
> Hope this helps.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230222/f0b649f7/attachment-0001.htm>
Hello!
On Wed, Feb 22, 2023 at 09:31:43PM -0500, Saint Michael wrote:
> how would this line look?
> try_files $uri $uri/ /index.html;
You have to remove this line completely (or comment it out by
using the "#" character at the start of the line).
> and how do set I the error log to the max level for this particular server
> {}?
> I am not getting any errors in /var/log/nginx/error.log
I would recommend configuring error_log at the global level only,
not in individual servers. Just keep error_log at the global
level, outside of the http{} block, and remove any other error_log
directives.
Using the level "info" is the most verbose mode you'll be able to
obtain from non-debug nginx builds. It is usually ok to run this
in production for a long time, especially when you are trying to
investigate some issues. It is also immediately shows that
logging is properly configured, as nginx will log some
notice-level messages at start.
--
Maxim Dounin
http://mdounin.ru/
Question:
if I don't have any like inside de
location / {}
how does nginx delivers an html file out of many possibly found in the root
for the location?
On Wed, Feb 22, 2023 at 9:48 PM Maxim Dounin <mdounin at mdounin.ru> wrote:
> Hello!
>
> On Wed, Feb 22, 2023 at 09:31:43PM -0500, Saint Michael wrote:
>
> > how would this line look?
> > try_files $uri $uri/ /index.html;
>
> You have to remove this line completely (or comment it out by
> using the "#" character at the start of the line).
>
> > and how do set I the error log to the max level for this particular
> server
> > {}?
> > I am not getting any errors in /var/log/nginx/error.log
>
> I would recommend configuring error_log at the global level only,
> not in individual servers. Just keep error_log at the global
> level, outside of the http{} block, and remove any other error_log
> directives.
>
> Using the level "info" is the most verbose mode you'll be able to
> obtain from non-debug nginx builds. It is usually ok to run this
> in production for a long time, especially when you are trying to
> investigate some issues. It is also immediately shows that
> logging is properly configured, as nginx will log some
> notice-level messages at start.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230222/b1f6b5f6/attachment.htm>
> Question:
> if I don't have any like inside de
> location / {}
> how does nginx delivers an html file out of many possibly found in the root for the location?
There is generally no need to specify location / { .. } if you don't provide any specific configuration or behavior for it.
Having just:
server {
root /some/path;
}
is enough to serve (static) files.
If there is a request to '/' by default nginx will try to look for (index.html http://nginx.org/en/docs/http/ngx_http_index_module.html#index or any other files in defined by that directive in given order.
rr
Hello!
On Thu, Feb 23, 2023 at 01:32:06PM +0200, Reinis Rozitis wrote:
> > Question:
> > if I don't have any like inside de
> > location / {}
> > how does nginx delivers an html file out of many possibly found in the root for the location?
>
> There is generally no need to specify location / { .. } if you don't provide any specific configuration or behavior for it.
>
> Having just:
>
> server {
> root /some/path;
> }
>
> is enough to serve (static) files.
I would rather recommend to always specify at least "location /",
even if it's empty.
While not specifying any locations mostly works, this causes nginx
to process requests in the "server location", which was originally
introduced as a purely technical one. Trying to process requests
in it might have various associated bugs.
--
Maxim Dounin
http://mdounin.ru/
Suppose that my default html file forn a location is xyz.html, but there
are hundreds. What is the canonical way to specify that and only that file
for a / {}.
On Thu, Feb 23, 2023, 8:03 AM Maxim Dounin <mdounin at mdounin.ru> wrote:
> Hello!
>
> On Thu, Feb 23, 2023 at 01:32:06PM +0200, Reinis Rozitis wrote:
>
> > > Question:
> > > if I don't have any like inside de
> > > location / {}
> > > how does nginx delivers an html file out of many possibly found in the
> root for the location?
> >
> > There is generally no need to specify location / { .. } if you don't
> provide any specific configuration or behavior for it.
> >
> > Having just:
> >
> > server {
> > root /some/path;
> > }
> >
> > is enough to serve (static) files.
>
> I would rather recommend to always specify at least "location /",
> even if it's empty.
>
> While not specifying any locations mostly works, this causes nginx
> to process requests in the "server location", which was originally
> introduced as a purely technical one. Trying to process requests
> in it might have various associated bugs.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20230223/f54f63c3/attachment.htm>
Hello!
On Thu, Feb 23, 2023 at 08:13:54AM -0500, Saint Michael wrote:
> Suppose that my default html file forn a location is xyz.html, but there
> are hundreds. What is the canonical way to specify that and only that file
> for a / {}.
Locations are for a given URI prefix, not for a particular file.
Locations define a configuration to be used for matching requests.
See http://nginx.org/r/location for the detailed description of
the location directive.
When mapping requests to the files, nginx simply concatenates the
document root, as defined by the "root" directive, and URI from
the requests. For example, given "/path/to/html" root and a request
to "/xyz.html", nginx will return the "/path/to/html/xyz.html" file.
If you want nginx to return only the particular file to all
requests matched by the location, the most simple approach would
be to use a rewrite (http://nginx.org/r/rewrite) to change the
URI:
location / {
rewrite ^ /xyz.html break;
}
Note though that this is not going to be a good solution to the
issues with likely non-existing files you are facing. Rather,
this will make such issues impossible to debug, and is generally
not recommended - unless you have good reasons to implement
something like this. Instead, I would recommend using normal
request processing and let nginx to normally return files under
the document root and reject requests to non-existing files.
Hope this helps.
--
Maxim Dounin
http://mdounin.ru/