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