Memcached/JSONP

[Marcus Clyne]

> Well, there's more than one way to do it, actually. A more concise and
> faster version is given below:
>
>     location /blah {
>         echo_before_body "$arg_callback(";
>
>         echo_duplicate 1 '{"dog":"$uri"}';
>
>         echo_after_body ")";
>     }
>
> The "echo_before_body" and "echo_after_body" directives work exactly
> in an output filter. And no extra cost of subrequests is needed here
> :D
>
> The output might be a bit ugly due to 1 extra new line:
>
>     ding1111111(
>     {"dog":"/blah/9999999.json"})
>   
What about :

location /blah {
        echo "$arg_callback({"dog":"$uri"})";
    }

?

:-)

That's only if the data can be generated from Nginx variables, though, 
which I was getting the impression it wasn't.


I was thinking of something like:

location /blah {
        echo "$arg_callback(";

        echo_location_async /subrequest

        echo ")";
    }

location /subrequest {

    (various options)
}

(as you previously suggested)

since if the data is not related to the request, it's probably better to 
store it elsewhere.

Inside the subrequest block, you could have a memcached pass (if the 
data is definitely going to be there), a try_files with memcached first 
/ fastcgi/proxy to update the data in memcached (if it might not be 
there), or a fastcgi/proxy pass, which utilizes Nginx's cache (this may 
be faster than using memcached to store the data).


Even better would be :

location /blah {
        echo -n "$arg_callback(";

        echo_location_async /subrequest

        echo -n ")";
    }


Where the '-n' works like the command-line version to not add a newline 
(a new feature perhaps?). :-)

Cheers,

Marcus.