Maxim,
First and foremost: thank you very much for your help.
I tried your way and, of course, it worked.
Now, there are still a few things I don't get.
> Key points are:
>
> 1. You always return NGX_DONE from handler.
>
> 2. You are responsible to call ngx_http_finalize_request() as
> you've retruned NGX_DONE.
Just to clarify things for me:
- When the handler returns NGX_OK, NGX_AGAIN or NGX_ERROR, nginx core calls
ngx_http_finalize_request() for you.
- When the handler returns NGX_DONE, nginx does nothing (so, you better have
setup another handler/callback before)
- When the handler returns an HTTP code > 300 (=SPECIAL_RESPONSE), nginx core
calls ngx_http_finalize_request() plus the special_response_handler (this is the
way error_page directives are implemented, I guess).
> > ngx_int_t ngx_http_xxx_do_post(ngx_http_request_t *r) {
> > [...]
> > rc = ngx_http_read_client_request_body(r, ngx_http_xxx_body_received);
> >
> > if (rc == NGX_ERROR || rc >= NGX_HTTP_SPECIAL_RESPONSE) {
> > return rc;
> > }
> >
> > if (rc == NGX_AGAIN) {
> > /* It will not call me again, but call the body_received. */
> > return NGX_AGAIN;
> > }
>
> No, NGX_AGAIN here means: setup http writer and call it again once
> write is possible on client connection. It is designed to be
> natural for code like
>
> return ngx_http_output_filter(r, &out);
Got it. Why the same pattern was not used for the body handler ? Using one
pattern for request handler and another for body handler is definitely
misleading and wannabe module developers like me are likely to fall in this
trap.
> Returning NGX_AGAIN in case of reading body will result in
> problems (exactly as you see). Use the above pattern instead.
I definitely will. The tricky part is that those problems appear only in very
specific situations (big BODY in and out). Honestly, I ran into this bug almost
"by luck".
Thanks again,
Antoine Bonavita.
>
> Maxim Dounin
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel@nginx.org
> http://nginx.org/mailman/listinfo/nginx-devel
>
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://nginx.org/mailman/listinfo/nginx-devel