I get a warning when placing it outside of a location block. I don’t
think it -needs- to be inside of one. Would be nice to team up with
the patch you made for the next release…
Thanks
I get a warning when placing it outside of a location block. I don’t
think it -needs- to be inside of one. Would be nice to team up with
the patch you made for the next release…
Thanks
On Thu, Mar 19, 2009 at 10:17:45PM -0700, mike wrote:
I get a warning when placing it outside of a location block. I don’t
think it -needs- to be inside of one. Would be nice to team up with
the patch you made for the next release…
I’m not sure that it should be done.
Could you show use case ?
2009/3/19 Igor S. [email protected]:
On Thu, Mar 19, 2009 at 10:17:45PM -0700, mike wrote:
I get a warning when placing it outside of a location block. I don’t
think it -needs- to be inside of one. Would be nice to team up with
the patch you made for the next release…I’m not sure that it should be done.
Could you show use case ?
for a site basically dedicated to a single app… no need for location /
{}
server {
listen 80;
server_name michaelshadle.com;
index index.php index.html;
root /home/mike/web/michaelshadle.com;
include /etc/nginx/defaults.conf;
include /etc/nginx/expires.conf;
try_files $uri $uri/ /wordpress/index.php?q=$uri;
location ~ .php$ {
fastcgi_pass 127.0.0.1:11000;
}
}
my current workaround:
server {
listen 80;
server_name michaelshadle.com;
index index.php index.html;
root /home/mike/web/michaelshadle.com;
include /etc/nginx/defaults.conf;
include /etc/nginx/expires.conf;
location / {
try_files $uri $uri/ /wordpress/index.php?q=$uri;
location ~ \.php$ {
fastcgi_pass 127.0.0.1:11000;
}
}
}
A nit bit-picky but I don’t see the need for the restriction, unless
the code is very difficult for it.
On Thu, Mar 19, 2009 at 10:43:43PM -0700, mike wrote:
for a site basically dedicated to a single app… no need for location / {}
fastcgi_pass 127.0.0.1:11000;
include /etc/nginx/defaults.conf;A nit bit-picky but I don’t see the need for the restriction, unless
the code is very difficult for it.
Actually, I have decided from the very start that each server {} should
have “location / {}” and it was surprise for me when people started to
use configurations as in the 1st example. There are even some bugfixes
related to this since I did not expect such usage.
I will think if try_files in server{} is possible. You may try the
attached
patch, it just enable try_files in server context (warning, I did not
test it).
well if this is something you would rather not support, then perhaps i
should go by your rules.
i try to keep my configurations simple, and it seemed like for most of
my sites i did not need the location / {} and it also conflicted
sometimes with other rules (probably due to incorrect modifiers and
user error)
i can try the patch if you’d like though, or i can start to make base
level location / {} in all my configs (honestly 90% of my sites dont
need any)
2009/3/19 Igor S. [email protected]:
On Fri, Mar 20, 2009 at 12:25:39AM -0700, mike wrote:
well if this is something you would rather not support, then perhaps i
should go by your rules.i try to keep my configurations simple, and it seemed like for most of
my sites i did not need the location / {} and it also conflicted
sometimes with other rules (probably due to incorrect modifiers and
user error)
A server has location context with empty name “”, therefore it should
work. If you have problems - report. However, if you have a complex
site,
it’s better to use “location /” as clearly visible fallback.
i can try the patch if you’d like though, or i can start to make base
level location / {} in all my configs (honestly 90% of my sites dont
need any)
Anyway, try to see if the patch works.
2009/3/20 Igor S. [email protected]:
Anyway, try to see if the patch works.
It appears to work properly (of course :))
On Fri, Mar 20, 2009 at 02:24:00AM -0700, mike wrote:
2009/3/20 Igor S. [email protected]:
Anyway, try to see if the patch works.
It appears to work properly (of course :))
Well, then I will enable try_files in server context.
On Fri, Mar 20, 2009 at 09:50:42AM -0700, mike wrote:
Please make note in the next release (which I assume includes this and
the other try_files patch) about it, so we can update the English wiki
with the allowed context in the config file. Thanks
Yes, it will in the next release.
Also I will probably include cache code in the release.
Please make note in the next release (which I assume includes this and
the other try_files patch) about it, so we can update the English wiki
with the allowed context in the config file. Thanks
2009/3/20 Igor S. [email protected]:
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs