On Mon, Feb 17, 2014 at 11:16:23PM +0100, B.R. wrote:
Hi there,
> Thanks for your help, Francis!
You're welcome.
> That's an amazingly detailed explanation.
It is. But be aware: it is not actually correct.
It covers some of the common cases, which may be good enough for you for now.
> The di
Thanks for your help, Francis!
That's an amazingly detailed explanation. The differences in behavior
between 'normal' arguments and the last one are the key but the doc does
not (cannot?) go into details about them.
---
*B. R.*
___
nginx mailing list
ngi
On Mon, Feb 17, 2014 at 02:13:14PM +0100, B.R. wrote:
Hi there,
> What I called 'error handler' was the final argument of the try_files
> directive, the one used if any other one fails to detect a valid
> file/directory.
So: the "uri" argument.
If try_files gets as far as the uri argument, ther
Sorry for my fluffy terminology.
What I called 'error handler' was the final argument of the try_files
directive, the one used if any other one fails to detect a valid
file/directory.
We ended concluding that:
try_files $uri $uri/; was invalid, looping internally for an infinite
amount of time
try
On Mon, Feb 17, 2014 at 12:42:28AM +0100, B.R. wrote:
Hi there,
> If I may, there is still a little something bothering me:
> The condition required for a loop to be created is that $uri (= /) doesn't
> match any file, thus redirecting and trying again.
> Why on Earth does '/' as error handler ma
Thanks for you time, Francis.
I understand the loop cycles (and thanks for the clarification about $uri
content).
If I may, there is still a little something bothering me:
The condition required for a loop to be created is that $uri (= /) doesn't
match any file, thus redirecting and trying again.
On Sun, Feb 16, 2014 at 11:00:07PM +0100, B.R. wrote:
Hi there,
> Right, I did not pay attention to that.
I think you're still not understanding it.
> However, when requesting the root (by typing b.cd in the browser), $uri
> should be empty, thus why can't '$uri/' act as '/' and redirect accord
Right, I did not pay attention to that.
However, when requesting the root (by typing b.cd in the browser), $uri
should be empty, thus why can't '$uri/' act as '/' and redirect accordingly?
---
*B. R.*
___
nginx mailing list
nginx@nginx.org
http://mailman
On Sun, Feb 16, 2014 at 08:43:45PM +0100, B.R. wrote:
Hi there,
> try_files $uri $uri/;
The final argument to "try_files" is special.
> Requesting b.cd in the browser ends up wth a HTTP 500 error:
> '[error] 12345#0: *42 rewrite or internal redirection cycle while
> internally red
Thanks for your input Francis.
What I suspected seemed old but I really don't understand the problem I am
facing.
Consider the following server configuration for some phpBB forum:
server {
listen 80;
server_name b.cd;
try_files $uri $uri/;
root
On Sat, Feb 15, 2014 at 12:29:00PM +0100, B.R. wrote:
> One could imagine a minimal server configured as such:
If you want the minimal config, start with an empty file and see what
you need to add to get it to work.
I suspect that
===
events{}
http{ server{} }
===
will probably work usefully.
One could imagine a minimal server configured as such:
in */nginx/nginx.conf:
http {
#All default http stuff, like MIME type inclusion, etc.
include conf.d/*.conf
}
in */nginx/conf.d/default.conf
server {
listen 80;
index index.html index.htm;
try_files $uri $uri/ /;
}
Howeve
12 matches
Mail list logo
