try_files problem

holstebm nginx-forum at nginx.us
Fri Jul 31 06:40:58 MSD 2009


Igor Sysoev Wrote:
-------------------------------------------------------
> On Thu, Jul 30, 2009 at 10:25:56AM -0400, holstebm
> wrote:
> 
> > Maxim Dounin Wrote:
> >
> --------------------------------------------------
> -----
> > > Hello!
> > > 
> > > On Tue, Jul 28, 2009 at 12:59:15PM +0400,
> Maxim
> > > Dounin wrote:
> > > 
> > > > Hello!
> > > > 
> > > > On Tue, Jul 28, 2009 at 01:43:57AM -0400,
> > > holstebm wrote:
> > > > 
> > > > > I can't get the following to work and,
> after
> > > reading and re-reading all the documentation
> I
> > > could find, am not sure if this is a bug or a
> > > restriction.
> > > > > 
> > > > > try_files @nocache @cache;
> > > > > 
> > > > > The thought here is @nocache will succeed
> if a
> > > cookie is present and @cache will succeed if
> not.
> > > > 
> > > > Try_files doesn't work this way.  It checks
> > > *files* and uses 
> > > > fallback in no one was found:
> > > > 
> > > > try_files /file1 /file2 @fallback;
> > > > 
> > > > Looks like
> > > > 
> > > >
> > >
> http://wiki.nginx.org/NginxHttpCoreModule#try_file
> 
> > > s 
> > > > 
> > > > has wrong description and should be
> > > re-translated from scratch. 
> > > 
> > > Just a note: it looks like description was
> changed
> > > to wrong one by 
> > > Merlincorey at 2009-07-14.  I've reverted
> this
> > > change and at least 
> > > it doesn't plain wrong now.
> > > 
> > > Note that original documentation has much
> more
> > > examples and covers 
> > > a bit more features of try_files (testing
> > > directories, ability to 
> > > return error code in 0.7.51+).  So we still
> need
> > > good translation 
> > > here.
> > > 
> > > Maxim Dounin
> > > 
> > 
> > Thanks for the insight!  I guess I was looking
> at these locations as 'virtual files and
> directories' and, therefore, didn't make the
> distinction
> > .
> > I think I understand the documentation provided
> but one thing is still unclear to me; How is the
> remaining directives in the block treated when
> there is a try_files at the beginning of the
> block?
> 
> First, directive order usually has no meaning.
> There is no difference between
> 
>      location ~ \.php$ {
>        try_files $uri @fallback;
>  
>        fastcgi_index index.php;
>        fastcgi_cache default;
>        fastcgi_cache_key $host$uri$args;
>        ...
>        fastcgi_pass	unix:xxxx;
>      }
> 
> and
> 
>      location ~ \.php$ {
>        fastcgi_index index.php;
>        fastcgi_cache default;
>        fastcgi_cache_key $host$uri$args;
>        ...
>        fastcgi_pass	unix:xxxx;
> 
>        try_files $uri @fallback;
>      }
> 
> > If try_files skips the remainder of the
> containing block upon success, I have a
> follow-up.
> > 
> >  Is there an easy way to eliminate the 2 or more
> argument restriction in try_files?  I've tried
> looking at the source but can't identify the arg
> checking or if the loop used for the files must
> run at least once (ala repeat....until type logic)
> in order to function.
> > 
> > For instance, this seems to work but I am forced
> to use an invalid file location - suggesting
> skipping remaining block upon try_files success:
> > 
> >     location ~ \.php$ {
> >       try_files /invalid @nocache;
> > 
> >       fastcgi_index index.php;
> >       fastcgi_cache default;
> >       fastcgi_cache_key $host$uri$args;
> >       ...
> >       fastcgi_pass	unix:xxxx;
> >     }
> > 
> >    location @nocache {
> >       fastcgi_index index.php;
> >       ...
> >       if(  ) {
> >         fastcgi_pass	unix:xxxx;
> >       }
> >    }
> 
> Your configuration is the same as
> 
>      location ~ \.php$ {
>        fastcgi_index index.php;
>        ...
>        if(  ) {
>          fastcgi_pass	unix:xxxx;
>        }
>     }
> 
> if the /invalid existance test fails always.
> 

Hello!  Thanks for the reply.  I looked again and, yes, as offered it is the same you say here.  I apologize but my example needs correction.  Then, perhaps, it will be easier to see what I am asking about.

Looking at my production server I see I put if conditions in BOTH the  location ~ \.php$ { } block AND the location @nocache block that encloses the  'fastcgi_pass	unix:xxxx;' in each case.  That's probably what makes this work for checking the cookie for caching purposes.  This is the corrected and accurate configuration I use:

     location ~ \.php$ {
       try_files /invalid @nocache;
 
       fastcgi_index index.php;
       fastcgi_cache default;
       fastcgi_cache_key $host$uri$args;
       ...
       if(   ) {
         fastcgi_pass	unix:xxxx;
       }
    }

    location @nocache {
       fastcgi_index index.php;
       ...
       if(  ) {
         fastcgi_pass	unix:xxxx;
       }
   }

I know this works for caching pages for users who are not logged in and bypassing the cache for users who are logged in.  I verified this by logging calls to my PHP backend, checking the existence of the cache files in the fastcgi cache directory and verifying the logged-in user-specific pages when logged in.

That's where the /invalid starts to look ugly and why I wonder where in the source the 2 or more argument restriction is enforced for the 'try_files' directive?  The /invalid really isn't needed and is only included because of that restriction.  This method would work without it.

Thanks, again, for the reply and I hope this clarifies my configuration.

> > Employing the /invalid is clumsy due to the two
> argument rule.  Otherwise this works as expected
> using the fastcgi_cache in the try_files
> containing block only if the  is not met.
> > 
> > I can do the patch myself if someone could point
> me in the right direction here.  Thanks, again!
> > 
> > Bret Holstein
> > 
> > > > For a while use original documentation in
> > > Russian:
> > > > 
> > > >
> > >
> http://sysoev.ru/nginx/docs/http/ngx_http_core_mod
> 
> > > ule.html#try_files
> > > > 
> > > > (try google translate if you have problems
> with
> > > Russian).
> > > > 
> > > > Maxim Dounin
> > > > 
> > > > > 
> > > > > The problem is, the first argument seems
> to be
> > > ignored.  I say that because, if I change JUST
> the
> > > try_files without changing any other lines in
> the
> > > configuration I get two different results. 
> In
> > > each case, the final argument in the try_files
> is
> > > always reached...cache displaying correctly
> when
> > > there is no cookie and a blank page if there
> is a
> > > cookie while try_files @cache @nocache
> displays
> > > correctly when there is a cookie but a blank
> page
> > > if there is not.
> > > > > 
> > > > > So is this a restriction or a bug on
> using
> > > internal locations in try_files?
> > > > > 
> > > > > Posted at Nginx Forum:
> > >
> http://forum.nginx.org/read.php?2,4504,4504#msg-45
> 
> > > 04
> > > > > 
> > > > >
> > 
> > Posted at Nginx Forum:
> http://forum.nginx.org/read.php?2,4504,4534#msg-45
> 34
> > 
> 
> -- 
> Igor Sysoev
> http://sysoev.ru/en/

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,4504,4635#msg-4635






More information about the nginx mailing list