BIG requests/responses to POST and post_handler return value

[Antoine BONAVITA]

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 at nginx.org
> http://nginx.org/mailman/listinfo/nginx-devel
>