> <antoine_bonavita@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
>




_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://nginx.org/mailman/listinfo/nginx-devel