Multiple subrequest in handler

Adrian Perez de Castro adrianperez at
Tue Sep 11 18:23:45 MSD 2007


I am quoting myself, just for the sake of completeness and share my
findings with the rest of the list :D

El Mon, 10 Sep 2007 14:54:15 +0200
Adrian Perez de Castro <adrianperez at> escribió:

> I took another look at the addition module, and it seems [...] to
> reorder buffers in the output chain [...]

After some investigation (correct me if I am wrong), I found that the
addition filter does that because when acting as a filter it has access
to the full contents of the output chain (?), but my content handler
only has access to the buffer it generates.

I am considering the technique Manlio Perillo in a previous post.
(If you want to check the original post, here you have a link to it: Quoting

>> 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 think I can fix up things by using the second one, so I can do:

  1. Subrequest for the header OR partial response with built-in header.
  2. Partial response with file listing table.
  3. Subrequest for the footer OR partial response with built-in footer.

I will be restructuring the code a bit to better accommodate to this
approach. Will this way subrequest output placed at the right places? I
am aware that I should try to understand better how Nginx handles
output, but in the meanwhile maybe you could give some advice...

As always, comments are welcome. Thank you in advance.


Adrian Perez de Castro               <adrianperez at>
Oficina de Software Libre
Universidade da Coruña        
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <>

More information about the nginx mailing list