File uploads and client_body_temp_temp problems

[Michael Nachbaur]

I find it hard to believe that, with all these sites working behind  
nginx that there isn't a better answer than "Switch web servers".   
There must be someone here doing file uploads, since it is a very  
common webapp requirement.

Is there anything anyone has done to reduce the impact of this  
problem?  I already switched from lighttpd to nginx, and I really  
don't want to have to switch it for yet another "flavour of the month"  
web server.

On 29-Jul-08, at 10:15 AM, Rapsey wrote:

> By default this is unfortunately impossible. It's what forced me to  
> move away from nginx and I had to use pound as my main proxy.
> Perhaps there is a third party module somewhere that does this.
>
>
> Sergej
>
> On Tue, Jul 29, 2008 at 7:00 PM, Michael Nachbaur  
> <mike at nachbaur.com> wrote:
> Hi, I'm running nginx as a reverse proxy for an Apache/mod_perl  
> application, and have a fancy-upload progress bar that measures the  
> amount of content uploaded.  If the script doesn't see any progress  
> after several seconds, the client-side JavaScript assumes the upload  
> has failed for some reason and restarts the upload.
>
> However, now that I have nginx running in front of Apache, it seems  
> to be buffering the uploaded content and isn't sending any of it to  
> Apache until the upload finishes (or at least until the upload  
> progresses long enough for the client-side to give up and retry).   
> Is there any way I can tell nginx to stop buffering and simply send  
> all the content to Apache as it recieves it?  I only am using nginx  
> for SSL and serving static files, so I don't want it to do anything  
> special to my dynamic URIs.
>
> Can anyone help me out with this, or tell me if there's a way my  
> Apache application can detect the upload in-progress within nginx?   
> As long as I can watch the upload progress I can be happy, but my  
> application needs to be made aware of the upload.
>
> Thank you
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20080729/4c92c35f/attachment.html>