Accessing subrequest output in memory
Peter Leonov
gojpeg at gmail.com
Sat Oct 16 13:29:22 MSD 2010
Hi Marcus,
On 16.10.2010, at 4:44, Eugaia <ngx.eugaia at gmail.com> wrote:
> Hi again,
>
> I've found the output that the module I'm trying to get this to work
> with (ngx_http_echo_module) sent the content directly to the parent
> request. I'm not sure if this is as a result of a generic feature,
> or something that should be fixed in echo - which I'll look into.
AFAICT, this is by desing. Yichun wrote about it in nearest past:
http://agentzh.spaces.live.com/Blog/cns!FF3A735632E41548!552.entry
>
> Cheers,
>
> Marcus.
>
> On 15/10/2010 20:59, Eugaia wrote:
>> Hi,
>>
>> I'm trying to get the output of an in-memory subrequest, but I
>> can't find where the output is stored.
>>
>> Basically, I'm doing :
>>
>> ...
>> ngx_uint_t flags;
>> ngx_http_post_subrequest_t *psr;
>> ngx_str_t location;
>> ngx_str_t *url_args;
>>
>> psr->handler = my_callback;
>> flags |= NGX_HTTP_SUBREQUEST_IN_MEMORY;
>>
>> ngx_http_subrequest (r, &location, url_args, &sr, psr, flags);
>> ...
>>
>> // waiting for for subrequest to process
>>
>> my_callback (ngx_http_request_t *sr, void *data, ngx_int_t rc)
>> {
>> ngx_http_request_t *r;
>>
>> r = sr->parent;
>> ...
>> // I want to be able to access the (body) output from the
>> subrequest here
>> }
>>
>> If the subrequest uses an upstream, I know I can access the output
>> using sr->upstream->buffer. However, if the subrequest does not
>> use upstreams, then this won't work. The output is not available
>> from sr->out - r->out is set to NULL at some point during the
>> output filtering. As far as I can make out, what I need to do is
>> find where the body output ngx_chain_t * struct is saved after all
>> the body filtering has been processed, but I'm struggling to find it.
>>
>> Can anyone tell me where it is, or where I can find the output?
>>
>> Note : I don't want to remove the in-memory flag because I don't
>> want the output flushed to the client.
>>
>> Thanks,
>>
>> Marcus.
Best regards,
Peter.
More information about the nginx-devel
mailing list