about the Guide to Nginx Module Development
manlio_perillo at libero.it
Mon Aug 20 13:58:18 MSD 2007
Evan Miller ha scritto:
> Manlio Perillo wrote:
>> Hi again.
>> I have decided to write mod_wsgi by myself, and I have fuond the Evan
>> Miller's guide very helful.
> Glad it was useful. I'll try to keep updating it with more info, but in
> the meantime I thought I'd try to answer your specific questions (below).
>> However I think that some important documentation is missing:
>> 1) The overall architecture of nginx
>> 2) nginx memory handling
> Nginx has a pool of memory associated with each request (r->pool), which
> is reclaimed at the end of the request. You can malloc memory with
> ngx_palloc(r->pool, BYTES). I'm not sure whether you can free memory
> allocated in this way manually.
I'm using the pool also for allocating memory for the
configuration_object (main e location), since I need to convert from
ngx_str_t to null terminating strings.
>> 3) how to read data from the request payload
> I'm not sure, actually; but check out
If I'm right, when calling a "normal" request handler, the entire
request body has been read by nginx, and stored in a temporary file or
in internal buffers.
However I do not understand this:
"""If the request body is more than the buffer, then the entire request
body or some part is written in a temporary file."""
Does nginx use only one buffer?
Does really nginx write a part of the request body in the buffer and a
part on a temporary file?
The question is simple:
- if the entire request body is in a file, I can pass to the WSGI
application a File object.
- if the entire request body is in one buffer, I can pass to the WSGI
application a StringIO object
If this is possible, I can keep the code as simple as possible!
>> 4) how to read and generate arbitrary headers
>> There is an headers attribute in the request struct, what is its
I have done some test, and this is not very hard.
The "hard" part is that some headers must be "parsed" and stored in
special attributes of the request object.
>> 5) More about chain links.
>> When sending the response body, we have two choices
>> (but I'm not sure):
>> - write the entire chain links and then pass it to the output filter
>> (so we buffer the entire response)
>> - create a partial response, create a buffer and call the output
>> filter, then create a new partial response, create a new buffer and
>> call the outputfilter, and so on.
> I believe that's correct.
The question here is: when I call the output filter function without
return from the handler function, does nginx try to send the data to the
Does nginx run a "main loop" cycle?
> When I research these issues more I'll add them to the guide.
> Good luck with mod_wsgi! I know it's a module a lot of people would find
I'm writing mod_wsgi with one design goal in mind: to be able to use
nginx as a small and robust server to serve WSGI applications.
nginx is not Apache and mod_wsgi is not a general purpose module: it
must be used to serve only one WSGI application with one nginx server.
The nginx code is really good!
Regards Manlio Perillo
More information about the nginx