correct usage of location context?

[Nick Pearson]

If you want to map a request to /test/x to /var/www/test/x instead of
/var/www/test/test/x, it sounds like you need a rewrite to remove "/test"
from the request URI.  There may be another way of doing this, but
basically:

...
location /test {
    root /var/www/test;
    rewrite  ^/test(.*)$  $1;
}
...

That will get rid of the "duplicate" /test in the final path nginx uses to
access the filesystem.  Also note that the new regular expression support in
the "location" should make it easy to have a single block (like above) for
many sites.

Nick


On Fri, Jun 12, 2009 at 1:31 PM, Szymon Polom <sp at winterstille.net> wrote:

> Cliff Wells wrote:
>
>  On Fri, 2009-06-12 at 18:23 +0100, lejeczek wrote:
>>
>>> would not it be a trailing(redundant) slash in location statement? -
>>> location /test
>>>
>>
> 1. The trailing slash doesn't matter, /test looks for either a file or
> directory (that's what nginx's error-log says to me at least). It shouldn't
> be looking for /test though, it should list/process the content from the
> filesystem as set by the root parameter (/var/www/test).
>
>  Also his root settings are wrong:
>>
>> location /test {
>>   root  /var/www;
>> }
>>
>
> 2. My root-settings are not wrong. I have many sites in /var/www and test
> should not be mapped to /var/www but to /var/www/test.
>
> With that mapping, I assume that calling http://example.com/test/foobarshould try to access /var/www/test/foobar on the filesystem and not
> /var/www/test/test/foobar like it does now.
>
> What I'm trying to achieve is to move away from a vhost-configuration to a
> multiple-apps/sites-configurations, e.g.
>
> example.com/railsapp1/* would access /var/www/railsapp1 and below only,
> example.com/railsapp2/* would access /var/www/railsapp2 and below only,
> example.com/phpapp1/* would access /var/www/phpapp2 and below only,
> example.com/ would access /var/www/static_html and below unless below is
> one of the above mentioned "virtual" URIs.
>
> PS: It's "awesome" how slow this mailing list is (I don't mean the response
> time, but the time the system managing this list takes to process an email
> and to deliver it out to subscribers).
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20090612/c5d306f5/attachment.html>