BIG requests/responses to POST and post_handler return value

[Antoine BONAVITA]

> <antoine_bonavita at yahoo.com>  wrote:
> > 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.
> >
> 
> Well, just to mind you, the rewrite  handler, access handler, and body
> handler all use its own convention of  return values and they're
> different in one way or another ;)
But still, the values are the same (NGX_DONE, NGX_AGAIN, etc.). Same words, 
different meanings. Not necessarily the easiest thing to grasp when learning. 
But I have been warned.

> Besides,  the specific meaning may change without notice because Igor
> Sysoev tends to  change his mind :)
So do I. And a lot of people. 

> If you'd call such things "traps", then I'd say  there's tons of them
> in the core.
Yeah... At least, I'll keep discovering things. That will give me material for 
my blog (www.nginx-discovery.com).

> Reading request bodies can be more  complicated in a rewrite/access
> phase handler (as compared to the content  handler in your example)
> because the protocol there is even more  complicated.
That was on my list of things to explore but I'm not there yet.

> > 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".
> >
> 
> No, you  definitely do not have to do things by luck because you do
> have access to the  complete source code. When in doubt, go reading the
> source.
The good old UTSL. Yes, I do that a lot. Except that the code is not the easiest 
thing I had to read. And it takes some time/effort to get used to the style, 
finding what the usual suspects are (ngx_http_finalize_request, 
ngx_http_terminate_request, etc.) and understanding what they are supposed to 
do.
But, from having done the same with proprietary software in the past (M$, not to 
name it), being able to read the code (and debug it) is definitely better...

> If you do  rely on luck while developing nginx modules, then I'd bet
> that you'll quickly  go out of luck and it's very likely you have
> broken things on your side  already :)
Actually, I was considering myself lucky to have run into the bug. It appears 
only on POST requests with big request and big response. All my other tests were 
fine... I try to avoid luck as much as I can. I always say "untested code 
doesn't work". But you cannot test a test case you don't know to exist...
If you have any recommendation on the best way to get going with this thing, I'm 
all ears...

> Relying on mail list mails or blog posts is not recommended  either,
> because there's so many important details that could be easily  missed
> intentionally or unintentionally in such  media.
Noticed that. "Devil is in the details" should be the tagline for nginx... ;)


> 
> Cheers,
> -agentzh
>