Nginx memcache for redirecta

Server NGINX
1

Hello,

I would like to know if i could use nginx’s memcache module to store
urls so i can create redirects based on variables.

Is this possible?

Thanks,

2

yes. :slight_smile:

And I have implemented a module called tinyurl for url redirection.
Source
is here: http://www.libing.name/nginx/ngx_http_tinyurl_module.c

I wish that will give you some help.

2009/11/3 Fernando Flórez [email protected]

3

Thanks a lot! Is there a way to do it without compiling extra modules?
I can modify the nginx conf but not compile anything on the server.

Thanks!

El 02/11/2009, a las 21:42, å¼ ç«‹å†° escribió:

4

2009/11/3 Fernando Flórez [email protected]:

Hello,

I would like to know if i could use nginx’s memcache module to store urls so
i can create redirects based on variables.

Is this possible?

Yes, it’s possible, with the excellent “eval” module (
Nginx eval module (v 1.0.1) ):

    location / {
        eval $my_real_url {
            set $memcached_key $request_uri;
            memcached_pass '127.0.0.1:11211';
        }
        proxy_pass $scheme://127.0.0.1:$server_port$my_real_url;
    }

assuming you have memcached set up at localhost:11211. Then store the
key-value pair /blah and /foo in your memcached:

$ set-memcached localhost:11211 /blah /foo

And access your nginx server this way:

$ curl ‘http://localhost/blah’

You’ll get the results of the location /foo.

Here I use “proxy_pass” in the example above because I dunno if
there’s a config file level directive for the nginx C function
ngx_http_internal_redirect. Using a “proxy” here is rather
inefficient.

I’ll add one (named echo_exec) later to my “echo” module anyway.

Cheers,
-agentzh

5

without extra module?

I do not know how to write the conf, it seems impossible.

2009/11/3 Fernando Flórez [email protected]

6

On Tue, Nov 3, 2009 at 11:04 AM, agentzh [email protected] wrote:

   location / {
       eval $my_real_url {
           set $memcached_key $request_uri;

It may be worth mentioning that the eval block, i.e., eval $foo { …
}, actually creates a temporary location for our memcached_pass
settings. An example of the temporary location looks like
“/eval_136351308”. So using the $uri variable to set the memcached key
won’t work here because $uri evaluates to the URL of the current
(sub)request.

Even $request_uri does not actually evaluates to the (unparsed form
of) main request’s URI due to a “bug” in ngx_http_subrequest which
simply passes the parent request’s r->unparsed_uri directly to the
newly-created subrequest’s unparsed_uri field. So we’re actually using
a “bug” as a “feature” here :wink:

Cheers,
-agentzh