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 <mdou...@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@nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-devel > > _______________________________________________ > nginx-devel mailing list > nginx-devel@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-devel -- Maxim Dounin http://nginx.org/en/donation.html _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
