Welcome! Log In Create A New Profile

Advanced

Re: BIG requests/responses to POST and post_handler return value

Antoine BONAVITA
February 23, 2011 12:04PM
> <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
Subject Author Views Posted

BIG requests/responses to POST and post_handler return value

Antoine BONAVITA 2184 February 22, 2011 04:36AM

Re: BIG requests/responses to POST and post_handler return value

Maxim Dounin 963 February 22, 2011 06:16AM

Re: BIG requests/responses to POST and post_handler return value

Antoine BONAVITA 1086 February 22, 2011 08:52AM

Re: BIG requests/responses to POST and post_handler return value

agentzh 912 February 22, 2011 10:34PM

Re: BIG requests/responses to POST and post_handler return value

Antoine BONAVITA 862 February 23, 2011 12:04PM

Re: BIG requests/responses to POST and post_handler return value

agentzh 1566 February 27, 2011 11:06PM

Re: BIG requests/responses to POST and post_handler return value

Antoine BONAVITA 1100 February 28, 2011 04:26PM



Sorry, you do not have permission to post/reply in this forum.

Online Users

Guests: 59
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready