3 messages in ru.sysoev.nginxRe: nginx-0.7.1
FromSent OnAttachments
Igor SysoevMay 26, 2008 2:41 am 
Rt IbmerMay 26, 2008 6:46 am 
Anton YuzhaninovMay 26, 2008 2:12 pm 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: nginx-0.7.1Actions...
From:Rt Ibmer (rtib@public.gmane.org)
Date:May 26, 2008 6:46:05 am
List:ru.sysoev.nginx

*) Change: now locations are searched in a tree.

Can you please elaborate on what this means exactly? Does this mean that
locations can be nested? I think so. Now even the bigger question - can
multiple location blocks match or once one matches no others will apply? Here
is what I mean. I want this:

location conditionMain1 {

location conditionChild1 { set some nginx config params; }

location conditionChild2 { set some additional nginx config params; } }

So in the above scenario I want it to be possible (based on the conditionChild1
and conditionChild2 regex) for BOTH conditionChild1 and 2 to match). Can this
be done? Or once conditionChild1 matches then conditionChild2 will not be
processed?

One reason I want this functionality is because certain nginx config options are
not available within an "if" block. For instance, as I wrote about in a previous
message here, proxy_intercept_errors does NOT work in an "if" block, even though
the error_page directive does.

For instance I have one main location block which matches lots of different urls
and page types, and I want to use an "if" condition to check the url for certain
page types and set proxy_intercept_errors and error_page specific to each "if"
condition block. But currently I cannot do this. So I am wondering if the nested
location block can help me by doing something like using a location block within
a location block where the inner location block will then effectively give me
the conditional regex functionality like an "if" block but allow me to set
proxy_intercept_errors conditionally since it is now in a location instead of
"if" block.

*) Change: the "none" parameter in the "ssl_session_cache" directive; now this is default parameter. Thanks to Rob Mueller.

So then am I correct to assume that ssl_session_timeout 5m has no impact then
unless ssl_session_cache is specifically declared with a value other than none?
In other words, with this change the default will be no ssl session caching?

Also can you please provide some background on why this change was made? Seems
like at least a small amount of ssl session caching would be appropriate, so now
I am wondering if there is something risky/dangerous about ssl caching (that
warranted this change) that I should be aware of. Thanks.