[PATCH] implement a $location variable

David Gwynne david at gwynne.id.au
Tue Oct 16 13:16:00 UTC 2012


On 16/10/2012, at 12:53 AM, Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!

ola,

> 
> On Mon, Oct 15, 2012 at 11:22:00AM +1000, David Gwynne wrote:
> 
>> this patch is actually from piotr sikora, and is part of coolkit 
>> already. this is just a port of it to stock nginx.
>> 
>> this makes the part of the request uri that matches the 
>> locations name available as a variable within a block. eg if you 
>> have location /foo { } and request /foo/bar/foo, $location will 
>> have the value /foo. if you have location ^~ /(foo|bar) and 
>> request /foo/bar/foo, $location will still have /foo in it. 
>> think of it as $0 for regex locations, but it works for 
>> non-regex location names too.
>> 
>> im running this in production now and its working great. it 
>> allows me to treat the locations name as a parameter to an 
>> applications front end controller without having to repeat the 
>> value within a location block.
> 
> Behaviour within regexp locations is counterintuitive, and 
> contradicts to what the variable does in a normal location.
> 
>> --- src/http/ngx_http_variables.c.orig  Tue Jul  3 03:41:52 2012
>> +++ src/http/ngx_http_variables.c       Thu Aug 23 10:32:22 2012
>> @@ -65,6 +65,8 @@ static ngx_int_t ngx_http_variable_request_filename(ng
>>  ngx_http_variable_value_t *v, uintptr_t data);
>> static ngx_int_t ngx_http_variable_server_name(ngx_http_request_t *r,
>>  ngx_http_variable_value_t *v, uintptr_t data);
>> +static ngx_int_t ngx_http_variable_location(ngx_http_request_t *r,
>> +    ngx_http_variable_value_t *v, uintptr_t data);
> 
> Just a side note: your mail client corrupts patches.

i usually use mutt, sorry on this one :/

> [...]
> 
>> +    if (clcf->regex) {
>> +        rc = ngx_regex_exec(clcf->regex->regex, &r->uri, captures, 3);
>> +
>> +        if (rc == NGX_REGEX_NO_MATCHED) {
>> +            return NGX_ERROR;
>> +        }
>> +
>> +        v->data = r->uri.data + captures[0];
>> +        v->len = captures[1] - captures[0];
> 
> Note that result is actually unstable in the regexp location case, 
> as the code re-executes regular expression against a possibly 
> changed URI.

is there a way to keep the equivalent of $0 around after the original regex is run?

dlg

> [...]
> 
> -- 
> Maxim Dounin
> http://nginx.com/support.html
> 
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel



More information about the nginx-devel mailing list