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( <no cookie> ) {
fastcgi_pass unix:xxxx;
}
}
location @nocache {
fastcgi_index index.php;
...
if( <cookie> ) {
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/
