Subrequests from body filters

[Maxim Dounin]

Hello!

On Mon, Mar 25, 2013 at 08:23:16PM +0400, Marat Dakota wrote:

> Yes, it is a part of the original request response generation.
> 
> I'll have a look, thanks. Is there a place to read about
> NGX_HTTP_SUBREQUEST_IN_MEMORY and NGX_HTTP_SUBREQUEST_WAITED except
> for source code?

Probably no.

> And is my current approach wrong even in spite of the conclusion that
> it is the original request response generation? And is it ok to call
> ngx_http_output_filter(r->main, out) in a post subrequest handler?

It is at least incorrect to return ngx_http_output_filter() result 
as a body filter result.

> 
> Thanks much!
> 
> --
> Marat
> 
> On Mon, Mar 25, 2013 at 8:01 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:
> > Hello!
> >
> > On Mon, Mar 25, 2013 at 07:41:16PM +0400, Marat Dakota wrote:
> >
> >> >> >> >> But is it ok to call next body filter in subrequest's body filter to
> >> >> >> >> produce output to main request?
> >> >> >> >> I mean ngx_http_next_body_filter(r->main, out).
> >> >> >> >
> >> >> >> > No.  You should call next body filter of the request you are
> >> >> >> > working with.  It's postpone filter responsibility to manage
> >> >> >> > subrequests output, and if you try to do this yourself instead -
> >> >> >> > result will be undefined.
> >> >> >>
> >> >> >> It seems to work as expected for me. How can I cause problems with this?
> >> >> >
> >> >> > Undefined behaviour sometimes appear to work as expected.  This
> >> >> > doesn't mean it's correct though.
> >> >> >
> >> >> > Depending on the exact place in a filter chain where you did it
> >> >> > and various other factors like timings, results may vary from
> >> >> > "nothing bad might happen, as r == r->main anyway" to "response
> >> >> > will completely incorrect as wrong filters will be applied to the
> >> >> > response body".
> >> >> >
> >> >> > Most trivial thing to test is probably a subrequest order, which
> >> >> > likely will be wrong in your case if first subrequest will take
> >> >> > longer to handle than second one.
> >> >>
> >> >> Subrequests order doesn't matter much for me. I feed my library (the
> >> >> one I write a Nginx module for) with a subrequests results in a
> >> >> whatever order and my library returns next chunk of response only when
> >> >> it is ready.
> >> >>
> >> >> My library has just one function to call. This function returns the
> >> >> next chunk of data (if any) to send as a response and/or a list of
> >> >> subrequests to make. In every call to subrequest body filter I pass
> >> >> subrequest's response to my library and get a new list of subrequests
> >> >> (if any) and a new chunk of final response (if any). And so on, until
> >> >> my library says it's done.
> >> >>
> >> >> And if I really do something wrong in terms of Nginx architecture,
> >> >> please, could you give me more details about how to achieve my goals
> >> >> correctly?
> >> >
> >> > I don't really see why you don't call ngx_http_next_body_filter(r,
> >> > out), which is perfectly correct.
> >>
> >> Because I'm getting a mess with the chunk order.
> >>
> >> Let's suppose I've made two subrequests in a handler.
> >>
> >> ngx_http_subrequest(...); // first
> >> ngx_http_subrequest(...); // second
> >>
> >> If I call ngx_http_next_body_filter(r, out) in a subrequest body
> >> filter, I get the following.
> >> Let's suppose we've received a response from the second subrequest
> >> before any data from the first subrequest. And my library said I
> >> should send "aaa" as a response (and I passed "aaa" to
> >> ngx_http_next_body_filter).
> >> Then, we've got a response from the first subrequest and my library
> >> said I should send "bbb" as a response. I would expect "aaabbb" as the
> >> final result. But real result would be "bbbaaa" (because
> >> ngx_http_subrequest for first subrequest is earlier).
> >>
> >> How to deal with this?
> >
> > So the part of code in your body filter which tried to call
> > ngx_http_output_filter(r->main, out) is actually not a part of a
> > body filter, but a original request response generation, right?
> >
> > For such a case I would recommend looking at
> > NGX_HTTP_SUBREQUEST_IN_MEMORY and NGX_HTTP_SUBREQUEST_WAITED
> > functionality, and using post subrequest handler to trigger
> > parent request content generation.
> >
> > --
> > Maxim Dounin
> > http://nginx.org/en/donation.html
> >
> > _______________________________________________
> > nginx-devel mailing list
> > nginx-devel at nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-devel
> 
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel

-- 
Maxim Dounin
http://nginx.org/en/donation.html