Hello!
On Tue, Jul 22, 2014 at 1:16 AM, chen wrote:
> I'm developing a custom nginx module that can handle HTTP POST requests
> from clients. After a few weeks of struggling in reading nging source code
> and maillists, I mark down a few
> questions that puzzling me for a while.
> 1) Why whould form-input-nginx-module register a rewrite phase handler
> instead of a custom clcf->handler (ref: empy_gif_module)?
>
Because ngx_form_input_module aims to work with various (other) nginx
content handler modules like ngx_proxy and ngx_empty_gif. If the
former registers a content handler in a location, other modules like
the latter no longer can. It's obvious that only one module can
register the content handler for a location.
> 2) After I grep ngx_http_read_client_request_body in nginx source code, I
> find that none of them will handle NGX_AGAIN return code. This is quite
> different from what you are doing in
> ngx_echo_module and ngx_http_read_client_request_body. Which one should I
> choose?
>
Most of the standard nginx modules like ngx_proxy calling
ngx_http_read_client_request_body just forward the NGX_AGAIN return
value to its own content handler's upper-level handler, i.e.,
ngx_http_finalize_request, directly. It does what they expect.
It does not hurt, however, if some modules like ngx_echo module handle
the return value specifically due to their own implementation
requirements. We do not have to do exactly the same as the standard
modules if the context changes (as long as we know what we are doing).
> 3) Why is that necessary add the ngx_http_request_empty_handler in the
> callback of ngx_http_read_client_request_body?
>
No, it is not necessary. It completely depends on your own
requirements because the "post_read" callback of
nx_http_read_client_request_body is your own "continuation" after the
request body reading operation. It's your decision (and
responsibility) to manage read/write event handlers for the downstream
connections.
I've noticed that ngx_form_input overrides r->read_event_handler to
ngx_http_request_empty_handler in its "post_read" callback function,
which is wrong in that context. I've already fixed it in its git
master:
https://github.com/calio/form-input-nginx-module/commit/8925aa3
Thank you for the catch!
BTW, you're strongly recommended to join the openresty-en mailing list
and discuss such technical details there:
https://groups.google.com/group/openresty-en That way other
knowledgeable developers can have a chance to help me answer your
questions (yes, I do receive a lot of user emails everyday) and other
newcomers with similar questions can also find answers in Google, for
example :)
I'm cc'ing the list.
Best regards,
-agentzh
