Patch: Refactor ngx_http_write_request_body into a filter
mdounin at mdounin.ru
Fri Jun 27 13:54:20 UTC 2014
On Thu, Jun 26, 2014 at 10:07:55PM +0300, grrm grrm wrote:
> 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.
More information about the nginx-devel