nginx-lua and nginx upload module

[Valery Kholodkov]

----- agentzh <agentzh at gmail.com> wrote:
> On Mon, Nov 28, 2011 at 5:45 PM, Valery Kholodkov
> <valery+nginxen at grid.net.ru> wrote:
> >>
> >> Happily we no longer have such limitations for nginx 0.8.54+ :)
> >
> > Explain?
> >
> 
> Now we can happily read and process the request body in both rewrite
> and access phase handlers in nginx 0.8.54+. And ngx_lua is already
> doing that for both the lua_need_request_body config directive and the
> "ngx.req.read_body()" Lua API.

I think we've been able to do that even before. But that's not point. The problem is not in what particular phase upload module will run, but that it must run whenever some module tries to read the request body. This kind of customisation is not supported by nginx yet.

> 
> >> Great! Just a quick example from my head:
> >>
> >>     location /upload {
> >>         upload_in_access_phase;
> >>         proxy_pass http://backend;
> >>     }
> >>
> >> That is, no longer introducing an internal location here for internal
> >> redirections ;)
> >
> > Doesn't look like API. We are talking about being able to use accelerated uploads feature from lua, aren't we?
> >
> 
> No, I think we're talking about making ngx_upload easier to work with
> other nginx modules, especially with those registering a content
> handler like ngx_lua, ngx_echo, ngx_proxy, and ngx_fastcgi.
> 
> The whole point here is to make ngx_upload read and process the
> request body in an earlier phase like "rewrite" and "access" phases,
> such that we can preserve the content handler for other modules and
> can eliminate internal redirects altogether to reduce runtime cost.
> 
> Sorry for the confusions in my previous emails :)

Again, the point is not in what particular phase it will run... And by the way, the costs of internal redirects are negligible.

-- 
Regards,
Valery Kholodkov