Turn off file upload buffering?

[Sam G.]

Thanks for thinking about it Igor... just wanted to throw in my  
support behind an upload progress module, we really could use it as  
well. Right now we just route all upload POST requests to a different  
subdomain which routes to port 81 on our frontend servers, which is  
running pound, which does nothing but transfer data to our backends  
as it comes in. It's not an ideal solution, but it works.

-Sam


On Nov 8, 2006, at 1:25 PM, Igor Sysoev wrote:

> On Tue, 7 Nov 2006, Ezra Zygmuntowicz wrote:
>
>> On Nov 7, 2006, at 12:35 AM, Igor Sysoev wrote:
>>
>>> On Mon, 6 Nov 2006, Ezra Zygmuntowicz wrote:
>>>> 	I am running mongrel behind nginx proxy and I am doing upload  
>>>> progess with mongrel. I need to know how to turn off ngxin file  
>>>> upload buffering. Right now nginx buffers the entire file upload  
>>>> to a tmp file before it sends it on to the proxied backend. Is  
>>>> there a way to turn this off so that nginx just does a pass  
>>>> through and lets the backend take care of buffering the file  
>>>> upload to disk?
>>> Currently nginx always buffer an upload because
>>> 1) it is accelerator
>>> 2) and to support fault tolerance: if some backend fails, nginx  
>>> can resend
>>>    the upload to next backend.
>>> I plan to add the upload progress module.
>>> Igor Sysoev
>>> http://sysoev.ru/en/
>>
>> 	Ok thanks for the info Igor. Is there anything I can do to help  
>> get the upload progress support in quicker? Maybe sponsor the  
>> development? Our customers really need a way to do upload progress  
>> and we use purely nginx and mongrel. I have custom mongrel  
>> extension that supports upload progress right in mongrel already,  
>> so is there no way to get an option for nginx to pass through the  
>> uploaded file? Or would that be too hard to add?
>
> I need to think some time.
>
>
> Igor Sysoev
> http://sysoev.ru/en/
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20061108/124f96b6/attachment.html>