Marcus Clyne ngx.eugaia at
Mon Dec 21 14:25:27 MSK 2009

> 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?). :-)



More information about the nginx mailing list