agentzh Wrote:
-------------------------------------------------------
> On Wed, Dec 23, 2009 at 8:36 AM, dylanz 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;
> }


Great point! What you proposed is almost there, but, I don't want the $query_string, but simply the path.
I've tried a few different combinations of location directives, but can't seem to get it right. For example:

If I made a request to:
/first/11111.ext?callback=222222

I'd want to look up the following path in Memcached:
/first/11111.ext

So, when I do that echo_async_location, I don't see how I'm able to extrapolate the path out.
If there was an internal variable that held the $uri, minus the $query_string, that would do it!
However, I don't think that exists at the moment.


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

That's perfect!


> > 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
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://nginx.org/mailman/listinfo/nginx