Memcached/JSONP
agentzh
agentzh at gmail.com
Wed Dec 23 06:55:01 MSK 2009
On Wed, Dec 23, 2009 at 8:36 AM, dylanz <nginx-forum at nginx.us> wrote:
> location /first {
> echo "before";
> echo_location_aysnc /second$request_uri;
> echo "after"
> }
>
> location /second(.*)\?(.*)^ {
> set $memcached_key $1; # needing this to be keyed on the request_path, not the entire uri
> memcached_pass 127.0.0.1;
> }
>
Well, I think you should not assume the query string part, i.e.,
"?xxx", can be specified in the location name :) Try the following:
location /first {
echo "before";
echo_location_async /second $request_uri;
echo "after";
}
location = /second {
set $memcached_key $query_string;
memcached_pass 127.0.0.1;
}
> The other concern is that if I was to patch the before/after echo methods, if they would be
> returned in the response even if there was no valid body being passed back? For example:
>
>
> location /first {
> echo_before_body -n "before";
> echo_location_aysnc /null; # this returns nothing
> echo_after_body -n "after"
> }
>
>
> In the above scenario, I think I'd have a response of "before after", even if the async call returned an empty response.
I think you should use custom error pages and the try_files directive
so that it fall back to an empty page or an null json object:
location @null_page {
echo_duplicate 1 "null"; # generate null
}
> Think I'm slowly getting there, and just need to make sure I'm picking the correct route :)
The ngx_echo module does very little itself, it just exposes the
internal API of the nginx core. So it often requires to utilize other
goodies in the ngx_http_core and/or ngx_http_rewrite modules ;)
Cheers,
-agentzh
More information about the nginx
mailing list