<bd9320b30903192217p3a438914w1bff0cf628e49239@mail.gmail.com> <20090320052912.GA72589@rambler-co.ru> <bd9320b30903192243v71c9df72s1a4baef9b14c198d@mail.gmail.com> On Thu, Mar 19, 2009 at 10:43:43PM -0700, mike wrote: > 2009/3/19 Igor Sysoev <is@rambler-co.ru>: > > On Thu, Mar 19, 2009 at 10:17:45PM -0700, mike wrote: > > > >> I get a warning when pby Igor Sysoev - Nginx Mailing List - English
<bd9320b30903192217p3a438914w1bff0cf628e49239@mail.gmail.com> 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 ? -- Igor Sysby Igor Sysoev - Nginx Mailing List - English
On Thu, Mar 19, 2009 at 01:37:08PM -0700, Cliff Wells wrote: > On Thu, 2009-03-19 at 13:22 -0700, Cliff Wells wrote: > > On Thu, 2009-03-19 at 13:21 -0700, Cliff Wells wrote: > > > > Not a good regex day for me... > > > Oops, should be > > > > - location ~ /images/subassets/*.gif { > > + location ~ /images/subassets/*.\.gif$ { > > locatiby Igor Sysoev - Nginx Mailing List - English
On Thu, Mar 19, 2009 at 12:18:50PM -0700, Merlin wrote: > You can also turn that into a regex location (or location with captures in > 0.7) and take it out of the main location block. I am not 100% sure, but my > intuition tells me that the location block performs much (well, at least a > little) better than the if block. It looks cleaner, anyway :). Yes, better and much, much cleaby Igor Sysoev - Nginx Mailing List - English
On Thu, Mar 19, 2009 at 01:26:29PM -0500, Nick Pearson wrote: > Here's a simplified version of I use the following to accomplish this, > inside my location block: > > if ($uri ~* (\.css|\.js|\.ico|\.gif|\.jpg|\.png)) { > break; > } > > Note that I haven't tested this simplified form directly, but I believe it > should work. "if ($uri ~" or "if ($requby Igor Sysoev - Nginx Mailing List - English
On Thu, Mar 19, 2009 at 04:53:31PM +0100, Otto Bretz wrote: > 2009/3/19 Igor Sysoev <is@rambler-co.ru>: > > On Thu, Mar 19, 2009 at 02:54:53PM +0100, Otto Bretz wrote: > > The attached patch includes all try_files functionality and bugfixes. > > Thanks, that patch works better but something still seems to be wrong > with my setup. > > If I try to access http:by Igor Sysoev - Nginx Mailing List - English
On Thu, Mar 19, 2009 at 02:54:53PM +0100, Otto Bretz wrote: > 2009/3/19 Igor Sysoev <is@rambler-co.ru>: > > > > The attached patch should fix the bug. > > I tried this patch together with the 0.6.3.5 try_files patch and I get > the following log message now: > 2009/03/19 14:30:10 2795#0: *43 rewrite or internal > redirection cycle while internal rediby Igor Sysoev - Nginx Mailing List - English
On Mon, Mar 16, 2009 at 09:44:30PM -0700, mike wrote: > for a site with multiple "if file does not exist, use this master > controller file" like wordpress, drupal, etc, does a config like this > make sense? > > because right now, it doesn't. > > the /blog one does, but the /second one doesn.t > > server { > listen 80; > seby Igor Sysoev - Nginx Mailing List - English
On Wed, Mar 18, 2009 at 12:33:15PM -0700, mike wrote: > well, i did it this way, and it seems to work... > > rewrite ^/sites/foo/index.php$ http://foo.com/ permanent; > rewrite ^/sites/coolsw(|/)$ http://foo.com/ permanent; > > # kill it from search engines > rewrite ^/sites/foo/(.*)$ /kill last; > location /kill { > return 404; > } However, it's better toby Igor Sysoev - Nginx Mailing List - English
On Wed, Mar 18, 2009 at 12:06:36PM -0700, mike wrote: > rewrites happen before location {} blocks are considered (if the > rewrite is on a global level) correct? > > so > > location /foo { > this will never be computed > } > > rewrite /foo/bar /somethingelse permanent; > > That's at least what it seems to me, unless I'm missing something. > > It doby Igor Sysoev - Nginx Mailing List - English
Changes with nginx 0.7.43 18 Mar 2009 *) Bugfix: a request was handled incorrectly, if a "root" directive used variables; the bug had appeared in 0.7.42. *) Bugfix: if a server listened on wildcard address, then the $server_addr variable value was "0.0.0.0"; the bug had appeared in 0.7.36. -- Igor Sysoeby Igor Sysoev - Nginx Mailing List - English
On Wed, Mar 18, 2009 at 11:33:03AM +0200, Reinis Rozitis wrote: > >On Thu, Feb 19, 2009 at 23:09, Gavin Kistner wrote: > >>Does there exist an english introduction to NginX config 'programming'? > > > >None, AFAIK. I had the same problem a few months ago when I switched > >to nginx. I ended up learning by example, getting nginx to do what I > >wanted, then fby Igor Sysoev - Nginx Mailing List - English
On Wed, Mar 18, 2009 at 04:23:48AM +0300, Maxim Dounin wrote: > Hello! > > On Wed, Mar 18, 2009 at 12:36:47AM +0300, Kirill A. Korinskiy wrote: > > > From: Kirill A. Korinskiy <catap@catap.ru> > > > > The nginx required privilege mode only on master process and only bind > > ports <1024. In linux proccess can bind ports <1024 in not privilege >by Igor Sysoev - Nginx Mailing List - English
On Tue, Mar 17, 2009 at 03:56:38AM +0000, Kinch Zhang wrote: > We're using nginx with PHP through FastCGI, and from nginx 0.7.36 on, the PHP > global variable $_SERVER["SERVER_ADDR"] is always 0.0.0.0, but with the same PHP > configuration, nginx 0.7.35 passed the correct server address, so I think > there's a bug in nginx 0.7.36+. The attached patch should fix the bug. -by Igor Sysoev - Nginx Mailing List - English
![]() |
![]() |
![]() |
![]() |
![]() |