Patch: Refactor ngx_http_write_request_body into a filter

Maxim Dounin mdounin at
Fri Jun 27 13:54:20 UTC 2014


On Thu, Jun 26, 2014 at 10:07:55PM +0300, grrm grrm wrote:

> Hi!
> I managed to fix the write to disk issue, but as you said the code now
> looks quite convoluted. Those ifs are horrible. Understandably I
> guess, when you try to move logic from different places into one place
> but it still depends on external context (rb->buf). My patch was
> mostly a try to pave the way to non-buffered request body processing
> in way similar to the response processing pipeline where all the work
> is done by the filters.
> I saw this feature in the tengine fork of nginx, however there the
> work is still done by a handler similar to write_to_file. Also, all
> the body data need to be copied inside the memory at least one time,
> which is not good.
> I also looked at the repose pipeline and there are two main methods of
> reading from the client - the nonbuffered and ngx_event_pipe_t. Do you
> think the pipe could be used in reverse (client->upstream)? Or would
> it even make sense to do it that way?

In theory it should be possible to use event pipe in any 
direction.  But I don't think that it would be easy to 
integrate it with various request body requirements.

> Also, do you have any work done into this direction (if you can
> comment on that)? Granted, my attempt was maybe too big a step.

I've previously posted an experimental patch which introduces an 
ability to insert filters into request body chain, which can be 
considered as a "work in this direction".

I think it should be implemented as another filter in 
the request body filter chain.  It will likely require various 
modification to the request body reading code though.

Maxim Dounin

More information about the nginx-devel mailing list