> 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.


_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx