Hello,

in the hope that this might get some attention and/or a statement from Igor.

Is there anything planned to get location blocks that are not
exclusive, but get merged with other matches instead?

I will quote the 3 mails about this, but in general it's about what
I've asked above.


Cheers and thanks,
Daniel

On Fri, May 14, 2010 at 1:30 AM, Michael Shadle wrote:

> Or a way to make "superlocations" where they are implemented no matter what.
> Things like regexes for expires headers and php processing right now can
> collide with other things.
>
> On May 13, 2010, at 4:09 PM, Daniel Hahler wrote:
>
>> Any news about this feature request?
>>
>> I've just implemented some basic "check if .htaccess" is present and use
>> it, but
>> all other locations do not get matched anymore.
>>
>>       location ~ ^/(.*)/(.*) {
>>               if (-f $document_root/$1/.htpasswd) {
>>                       error_page 599 = @auth;
>>                       return 599;
>>               }
>>       }
>>       location @auth {
>>               auth_basic "Password-protected";
>>               auth_basic_user_file $document_root/$1/.htpasswd;
>>       }
>>
>>
>> On Sun, Jul 19, 2009 at 2:22 PM, Michael Shadle <mike503@gmail.com> wrote:
>>>
>>> Igor,
>>> right now any time you have to protect a location, you have to put in
>>> a second location block for php. You've said yourself this isn't a
>>> highly suggested method.
>>>
>>> I've also run into issues where my expires headers can sometimes
>>> conflict with things...
>>>
>>> would there be some way to implement some sort of global location
>>> block method? perhaps it gets applied -after- the normal location
>>> logic, and has a new marker?
>>>
>>> that way we could safely apply things like expires headers or a php
>>> block -after- any sort of locations are defined. below the php block
>>> should be unnecessary as it should inherit from the parent but it
>>> doesn't. i've got some more complex setups too that get hard to
>>> support due to having regexps and "stop processing" instructions in
>>> place, but without them the site doesn't work properly, etc...
>>>
>>> server {
>>>       listen 80;
>>>       server_name foo.com;
>>>       index index.php index.html;
>>>       root /home/foo/docroot.com;
>>>       include /etc/nginx/defaults.conf;
>>>      location ~* \.(jpg|jpeg|gif|css|png|js|ico|html)$ {
>>>          expires max;
>>>      }
>>>       location ^~ /blog/wp-admin {
>>>               auth_basic "wordpress";
>>>               auth_basic_user_file /path/to/.htpasswd;
>>>               location ~ \.php$ {
>>>                       fastcgi_pass 127.0.0.1:11000;
>>>               }
>>>       }
>>>      location ~ \.php$ {
>>>               fastcgi_pass 127.0.0.1:11000;
>>>       }
>>> }
>>>
>>> Maybe instead have something like this, which would apply this
>>> location block -after- all others are done...
>>>
>>>      location :~ \.php$ {
>>>               fastcgi_pass 127.0.0.1:11000;
>>>       }
>>>
>>> I picked ":" randomly. Not sure what the best thing is. ^~* are taken,
>>> # is comments, $ is variables, @ is named location, + - & % : ?  are
>>> the only chars left I can think, unless you somehow figured out how to
>>> make it use a keyword like
>>>
>>> location :~ \.php$ global {
>>>
>>> but I don't know how that will work...
>>>
>>> Just an idea. Would simplify configuration a lot. I wind up hitting
>>> the expires stuff a lot when it should be matching another location
>>> instead, but because it's a .js file, it doesn't, so I have to wind up
>>> nesting the expires stuff inside of the location block...
>>>
>>> This would help solve some of my issues with locations. That's
>>> probably the most complicated thing in nginx.
>>>

--
http://daniel.hahler.de/

_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx