Ok, we've written asynchronous resolver and it seems to work properly.

However, we have problems with subrequests.. We thought about them at the very beginning, we tried to understand their mechanism by reading SSI filter source code, but it was really complicated, so we've written our own module to do that.

For example - when I use subrequest in simplest way:

ngx_http_myfilter_body_filter(..)
if(r == r->main) {
(...)
ngx_http_subrequest(...)
}
ngx_http_next_body_filter(...)
}

result of that subrequest will be send to the client - we don't want that.
Ofc I can do something like that:

if(r == r->main)
{
ngx_http_subrequest(...)
return ngx_http_next_body_filter(r, in);
} else {
return ngx_http_next_body_filter(r, NULL);
}

but this isn't probably best way to do that... This will "kill" any subrequest, not only ours. In SSI this problem is solved in some way, but I can't find how. ;)

Another problem - reading result of subrequest in registered callback.
In SSI there is a function (registered as callback for some subrequests):

static ngx_int_t
ngx_http_ssi_set_variable(ngx_http_request_t *r, void *data, ngx_int_t rc)
{
ngx_str_t *value = data;
if (r->upstream) {
value->len = r->upstream->buffer.last - r->upstream->buffer.pos;
value->data = r->upstream->buffer.pos;
}
return rc;
}

Result is taken from r->upstream, but why? Why upstream module is used? What will happen if subrequest handles static file?

And last, but not least - parallel subrequests.
Evan Miller says that this is really complicated etc.
http://www.evanmiller.org/nginx-modules-guide-advanced.html#subrequests-parallel
SSI source code isn't clear for me, but what about that code:

for(...) {
if (ngx_http_subrequest(...) != NGX_OK)
return NGX_ERROR;
}

This should enqueue some subrequest and nginx should process them "in parallel" (almost, as it's one thread). Am I wrong? What more can I do to simulate parallelism?