# Can't upload big files via nginx as reverse proxy

**URL:** <https://www.ruby-forum.com/t/cant-upload-big-files-via-nginx-as-reverse-proxy/220287>\
**Category:** NGINX\
**Created:** [June 5, 2012, 9:33am UTC](https://www.ruby-forum.com/t/cant-upload-big-files-via-nginx-as-reverse-proxy/220287 "2012-06-05T09:33:59Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![aris](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/258eb7/32.png) [@aris](https://www.ruby-forum.com/u/aris)\
**Post date:** [June 5, 2012, 9:33am UTC](https://www.ruby-forum.com/t/cant-upload-big-files-via-nginx-as-reverse-proxy/220287/1 "2012-06-05T09:33:59Z")

</div>

Hey.

In my env, the layout is:

client ↔ nginx ↔ jetty

In the client, there is a control. I tried to upload a  
file with size of 3.7MB. In the client request, the content type is  
“multipart/form-data”, and there is an “Expect: 100-continue” header.

Through tcpdump, I could see nginx immediately return an “HTTP/1.1 100  
Continue” response, and started to read data. After buffering the  
uploaded data, nginx then started to send them to jetty. However in this  
time, no “Expect: 100-continue” header was proxied because HTTP/1.0 is  
used.

After sending part of data, nginx stopped continuing to proxy the rest  
of data, but the connection is kept. After 30s, jetty reports time out  
exception and returned an response. Nginx finally proxied this response  
back to client.

I simply merged all the tcp segments which was sent from nginx to jetty,  
and found only 400K bytes are proxied.

My nginx config is quite simple, just

server {  
listen 80;  
location / {  
proxy\_pass [http://upstream](http://upstream);  
}  
}

All proxy buffer config was not explicitly set so the default values  
were applied. I tried to “proxy\_buffering off;” and re-do the experiment  
above and find the result was same.

I also tried to observe the temp file written by nginx but it’s  
automatically removed when everything is done. Any way to keep it?

Therefore, I’m wondering is this expected? Did I make mistakes for  
configuring proxy buffers? Do I have to use the third party “upload”  
module ([http://www.grid.net.ru/nginx/upload.en.html](http://www.grid.net.ru/nginx/upload.en.html)) to make it work?

Many thanks.

Posted at Nginx Forum:

> **[Can't upload big files via nginx as reverse proxy](https://forum.nginx.org/read.php?2,227175,227175#msg-227175)**
>
> Hey. In my env, the layout is: client \<--\> nginx \<--\> jetty In the client, there is a \<input type=file\> control. I tried to upload a file with size of 3.7MB. In the client request, the content type is...

---

<div class="post-metadata">

**Author:** ![speedfirst](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/e19adc/32.png) [@speedfirst](https://www.ruby-forum.com/u/speedfirst)\
**Post date:** [June 5, 2012, 9:39am UTC](https://www.ruby-forum.com/t/cant-upload-big-files-via-nginx-as-reverse-proxy/220287/2 "2012-06-05T09:39:50Z")

</div>

by the way, my client request is a POST request.

Posted at Nginx Forum:

> **[Re: Can't upload big files via nginx as reverse proxy](https://forum.nginx.org/read.php?2,227175,227176#msg-227176)**
>
> Hey. In my env, the layout is: client \<--\> nginx \<--\> jetty In the client, there is a \<input type=file\> control. I tried to upload a file with size of 3.7MB. In the client request, the content type is...

---

<div class="post-metadata">

**Author:** ![speedfirst](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/e19adc/32.png) [@speedfirst](https://www.ruby-forum.com/u/speedfirst)\
**Post date:** [June 5, 2012, 11:25am UTC](https://www.ruby-forum.com/t/cant-upload-big-files-via-nginx-as-reverse-proxy/220287/3 "2012-06-05T11:25:37Z")

</div>

Thanks for your quick response.

In my config, client\_max\_body\_size is set to 0. Does it mean  
“unlimited”?

I made this test in two version, 0.9.3 and 1.2.0. Both have the same  
problem.

Posted at Nginx Forum:

> **[Re: Can't upload big files via nginx as reverse proxy](https://forum.nginx.org/read.php?2,227175,227180#msg-227180)**
>
> Hey. In my env, the layout is: client \<--\> nginx \<--\> jetty In the client, there is a \<input type=file\> control. I tried to upload a file with size of 3.7MB. In the client request, the content type is...

---

<div class="post-metadata">

**Author:** ![speedfirst](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/e19adc/32.png) [@speedfirst](https://www.ruby-forum.com/u/speedfirst)\
**Post date:** [June 5, 2012, 9:55am UTC](https://www.ruby-forum.com/t/cant-upload-big-files-via-nginx-as-reverse-proxy/220287/4 "2012-06-05T09:55:01Z")

</div>

Hello!

On Tue, Jun 05, 2012 at 03:33:24AM -0400, speedfirst wrote:

> Through tcpdump, I could see nginx immediately return an “HTTP/1.1 100  
> Continue” response, and started to read data. After buffering the  
> uploaded data, nginx then started to send them to jetty. However in this  
> time, no “Expect: 100-continue” header was proxied because HTTP/1.0 is  
> used.

So far this is expected behaviour.

> After sending part of data, nginx stopped continuing to proxy the rest  
> of data, but the connection is kept. After 30s, jetty reports time out  
> exception and returned an response. Nginx finally proxied this response  
> back to client.
> 
> I simply merged all the tcp segments which was sent from nginx to jetty,  
> and found only 400K bytes are proxied.

This is obviously not expected.

Anything in error log? Could you please provide tcpdump and debug  
log? It would be also cool to see which version of nginx you are  
using, i.e. please provide “nginx -V” output, and a full config.

> My nginx config is quite simple, just
> 
> server {  
> listen 80;  
> location / {  
> proxy\_pass [http://upstream](http://upstream);  
> }  
> }

This misses at least “client\_max\_body\_size” as by default 3.5MB  
upload will be just rejected.

> All proxy buffer config was not explicitly set so the default values  
> were applied. I tried to “proxy\_buffering off;” and re-do the experiment  
> above and find the result was same.

Proxy buffers, as well as proxy\_buffering, doesn’t matter, as it  
only affects sending response from an upstream to a client.

> I also tried to observe the temp file written by nginx but it’s  
> automatically removed when everything is done. Any way to keep it?

client\_body\_in\_file\_only on;

See here for details:

> **[Module ngx\_http\_core\_module](http://nginx.org/en/docs/http/ngx_http_core_module.html#client_body_in_file_only)**
>
> This directive appeared in version 1.11.8.

Maxim D.

---

<div class="post-metadata">

**Author:** ![speedfirst](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/e19adc/32.png) [@speedfirst](https://www.ruby-forum.com/u/speedfirst)\
**Post date:** [June 5, 2012, 12:48pm UTC](https://www.ruby-forum.com/t/cant-upload-big-files-via-nginx-as-reverse-proxy/220287/5 "2012-06-05T12:48:35Z")

</div>

Hello!

On Tue, Jun 05, 2012 at 06:08:30AM -0400, speedfirst wrote:

[…]

> 2012/06/06 01:27:37 [debug] 15621#0: \*5 http read client request body  
> 2012/06/06 01:27:37 [debug] 15621#0: \*5 http client request body recv  
> 1528  
> 2012/06/06 01:27:37 [debug] 15621#0: \*5 http client request body rest 0

Ok, so the request body is read from a client without any problems.

[…]

> 2012/06/06 01:27:37 [debug] 15621#0: \*5 zmauth: prepare route for proxy  
> … ..\<-- choose the upstream route  
> 2012/06/06 01:27:37 [debug] 15621#0: \*5 zmauth: prepare upstream  
> connection, try: 1

Are you able to reproduce the problem without 3rd party  
modules/patches? (Unlikely it’s related in this particular case,  
but just to make sure.)

> 2012/06/06 01:27:37 [debug] 15621#0: \*5 http upstream send request  
> 2012/06/06 01:27:40 [debug] 15621#0: \*5 http upstream request:  
> “/service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset”  
> 2012/06/06 01:27:40 [debug] 15621#0: \*5 http upstream send request  
> handler  
> 2012/06/06 01:27:40 [debug] 15621#0: \*5 http upstream send request  
> 2012/06/06 01:27:44 [debug] 15621#0: \*5 http upstream request:  
> “/service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset”  
> … … \<— tens of similar log entires

It’s sad you skipped them all, and only did debug\_http log. With  
full debug log it would be clearly visible sending request goes on  
(i.e. how many bytes are sent).

> 2012/06/06 01:28:22 [debug] 15621#0: \*5 http upstream process header  
> 2012/06/06 01:28:22 [debug] 15621#0: \*5 http proxy status 200 “200 OK”

On the other hand, it looks like sending of the request is still  
in progress, and upstream server replies before the request was  
completely sent. It might indicate it just doesn’t wait long  
enough, and the problem is in the backend (and slow connectivity  
to the backend).

I don’t see any pause in request sending you’ve claimed in your  
initial message.

(and see below)

> s:163  
> 2012/06/06 01:28:22 [debug] 15621#0: \*5 http cacheable: 0  
> 2012/06/06 01:28:22 [debug] 15621#0: \*5 http upstream process upstream  
> 2012/06/06 01:28:23 [debug] 15621#0: \*5 http upstream request:  
> “/service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset”  
> 2012/06/06 01:28:23 [debug] 15621#0: \*5 http upstream send request  
> handler  
> 2012/06/06 01:28:57 [debug] 15621#0: \*5 http upstream request:  
> “/service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset”

On the other hand, here is ~ 30s pause you’ve probably talked  
about. It might indicate that upstream tries to send headers  
before “receiving and interpreting a request message” (as per HTTP  
RFC2616 it should do it “after”), which confuses nginx and makes  
it to think further body bytes aren’t needed.

You may want to dig further into what goes on on the backend to  
understand the real problem.

Maxim D.

---

<div class="post-metadata">

**Author:** ![speedfirst](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/e19adc/32.png) [@speedfirst](https://www.ruby-forum.com/u/speedfirst)\
**Post date:** [June 5, 2012, 12:08pm UTC](https://www.ruby-forum.com/t/cant-upload-big-files-via-nginx-as-reverse-proxy/220287/6 "2012-06-05T12:08:51Z")

</div>

retry the test while client\_max\_body\_size=0;  
The size of tmp file is as expected, about 3.7M :  
root@zm-dev03:/opt/data/tmp/nginx/client# ll 0000000001  
-rw------- 1 speedfirst speedfirst 3914486 2012-06-06 01:27 0000000001

Here is the client script from curl:  
curl -v -u removed\_email\_address@domain.invalid:test123 -F  
“file=@test.tgz;filename=test.tgz;type=application/x-compressed-tar”  
“[http://dev03.eng.test.com/service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset](http://dev03.eng.test.com/service/home/removed_email_address@domain.invalid/?fmt=tgz&resolve=reset)”

Here is the debug\_http nginx log.  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http process request line  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http request line: “POST  
/service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset HTTP/1.1”  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http uri:  
“/service/home/removed\_email\_address@domain.invalid/”  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http args:  
“fmt=tgz&resolve=reset”  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http exten: “”  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http process request header  
line  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http header: “Authorization:  
Basic YWRtaW5Aem0tZGV2MDMuZW5nLnZtd2FyZS5jb206dGVzdDEyMw==”  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http header: “User-Agent:  
curl/7.22.0 (x86\_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1  
zlib/1.2.3.4 libidn/1.23 librtmp/2.3”  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http header: “Host:  
[dev03.eng.vmware.com](http://dev03.eng.vmware.com)”  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http header: “Accept: _/_”  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http header: “Content-Length:  
3914486”  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http header: “Expect:  
100-continue”  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http header: “Content-Type:  
multipart/form-data; boundary=----------------------------f9dbdf4f72b4”  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http header done  
2012/06/06 01:27:35 [debug] 15621#0: \*5 rewrite phase: 0  
2012/06/06 01:27:35 [debug] 15621#0: \*5 test location: “/”  
2012/06/06 01:27:35 [debug] 15621#0: \*5 using configuration “/”  
2012/06/06 01:27:35 [debug] 15621#0: \*5 generic phase: 4  
2012/06/06 01:27:35 [debug] 15621#0: \*5 generic phase: 5  
2012/06/06 01:27:35 [debug] 15621#0: \*5 access phase: 6  
2012/06/06 01:27:35 [debug] 15621#0: \*5 access phase: 7  
2012/06/06 01:27:35 [debug] 15621#0: \*5 post access phase: 8  
2012/06/06 01:27:35 [debug] 15621#0: \*5 send 100 Continue  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http read client request body  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http client request body recv  
-2  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http client request body rest  
3914486  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http finalize request: -4,  
“/service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset” a:1,  
c:2  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http request count:2 blk:0  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http run request:  
“/service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset”  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http read client request body  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http client request body recv  
174  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http client request body rest  
3914312  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http client request body recv  
-2  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http client request body rest  
3914312  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http run request:  
“/service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset”  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http read client request body  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http client request body recv  
1360  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http client request body rest  
3912952  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http client request body recv  
-2  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http client request body rest  
3912952  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http run request:  
“/service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset”  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http read client request body  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http client request body recv  
1360  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http client request body rest  
3911592  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http client request body recv  
1360  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http client request body rest  
3910232  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http client request body recv  
-2  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http client request body rest  
3910232  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http run request:  
“/service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset”  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http read client request body  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http client request body recv  
1360  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http client request body rest  
3908872  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http client request body recv  
-2  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http client request body rest  
3908872  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http run request:  
“/service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset”  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http read client request body  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http client request body recv  
1360  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http client request body rest  
3907512  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http client request body recv  
-2  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http client request body rest  
3907512  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http run request:  
“/service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset”  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http read client request body  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http client request body recv  
1218  
2012/06/06 01:27:35 [notice] 15621#0: \*5 a client request body is  
buffered to a temporary file  
/opt/zimbra/data/tmp/nginx/client/0000000001, client: 10.112.117.117,  
server: , request: “POST  
/service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset HTTP/1.1”,  
host: “[dev03.test.com](http://dev03.test.com)”  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http client request body recv  
1502  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http client request body rest  
3904792  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http client request body recv  
-2  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http client request body rest  
3904792  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http run request:  
“/service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset”  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http read client request body  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http client request body recv  
1360  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http client request body rest  
3903432  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http client request body recv  
-2  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http client request body rest  
3903432  
2012/06/06 01:27:35 [debug] 15621#0: \*5 http run request:  
“/service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset”  
… … … ← tens of similar log entries  
2012/06/06 01:27:37 [debug] 15621#0: \*5 http read client request body  
2012/06/06 01:27:37 [debug] 15621#0: \*5 http client request body recv  
1360  
2012/06/06 01:27:37 [debug] 15621#0: \*5 http client request body rest  
1528  
2012/06/06 01:27:37 [debug] 15621#0: \*5 http client request body recv  
-2  
2012/06/06 01:27:37 [debug] 15621#0: \*5 http client request body rest  
1528  
2012/06/06 01:27:37 [debug] 15621#0: \*5 http run request:  
“/service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset”  
2012/06/06 01:27:37 [debug] 15621#0: \*5 http read client request body  
2012/06/06 01:27:37 [debug] 15621#0: \*5 http client request body recv  
1528  
2012/06/06 01:27:37 [debug] 15621#0: \*5 http client request body rest 0  
2012/06/06 01:27:37 [debug] 15621#0: \*5 http init upstream, client  
timer: 0  
2012/06/06 01:27:37 [debug] 15621#0: \*5 http script copy:  
"X-Forwarded-For: "  
2012/06/06 01:27:37 [debug] 15621#0: \*5 http script var:  
“10.112.117.117”  
2012/06/06 01:27:37 [debug] 15621#0: \*5 http script copy: "

"  
2012/06/06 01:27:37 [debug] 15621#0: \*5 http script copy: "Host: "  
2012/06/06 01:27:37 [debug] 15621#0: \*5 http script var:  
“[dev03.test.com](http://dev03.test.com)”  
2012/06/06 01:27:37 [debug] 15621#0: \*5 http script copy: "

"  
2012/06/06 01:27:37 [debug] 15621#0: \*5 http script copy: "Connection:  
close

"  
2012/06/06 01:27:37 [debug] 15621#0: \*5 http proxy header:  
“Authorization: Basic  
YWRtaW5Aem0tZGV2MDMuZW5nLnZtd2FyZS5jb206dGVzdDEyMw==”  
2012/06/06 01:27:37 [debug] 15621#0: \*5 http proxy header: “User-Agent:  
curl/7.22.0 (x86\_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1  
zlib/1.2.3.4 libidn/1.23 librtmp/2.3”  
2012/06/06 01:27:37 [debug] 15621#0: \*5 http proxy header: “Accept:  
_/_”  
2012/06/06 01:27:37 [debug] 15621#0: \*5 http proxy header:  
“Content-Length: 3914486”  
2012/06/06 01:27:37 [debug] 15621#0: \*5 http proxy header:  
“Content-Type: multipart/form-data;  
boundary=----------------------------f9dbdf4f72b4”  
2012/06/06 01:27:37 [debug] 15621#0: \*5 http proxy header:  
"POST /service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset  
HTTP/1.0

X-Forwarded-For: 10.112.117.117

Host: [dev03.test.com](http://dev03.test.com)

Connection: close

Authorization: Basic  
YWRtaW5Aem0tZGV2MDMuZW5nLnZtd2FyZS5jb206dGVzdDEyMw==

User-Agent: curl/7.22.0 (x86\_64-pc-linux-gnu) libcurl/7.22.0  
OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3

Accept: _/_

Content-Length: 3914486

Content-Type: multipart/form-data;  
boundary=----------------------------f9dbdf4f72b4

"  
2012/06/06 01:27:37 [debug] 15621#0: \*5 http cleanup add:  
0000000001D28F58  
2012/06/06 01:27:37 [debug] 15621#0: \*5 zmauth: prepare route for proxy  
… …\<-- choose the upstream route  
2012/06/06 01:27:37 [debug] 15621#0: \*5 zmauth: prepare upstream  
connection, try: 1  
2012/06/06 01:27:37 [debug] 15621#0: \*5 http upstream connect: -2  
2012/06/06 01:27:37 [debug] 15621#0: \*5 http upstream request:  
“/service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset”  
2012/06/06 01:27:37 [debug] 15621#0: \*5 http upstream send request  
handler  
2012/06/06 01:27:37 [debug] 15621#0: \*5 http upstream send request  
2012/06/06 01:27:37 [debug] 15621#0: \*5 http upstream request:  
“/service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset”  
2012/06/06 01:27:37 [debug] 15621#0: \*5 http upstream send request  
handler  
2012/06/06 01:27:37 [debug] 15621#0: \*5 http upstream send request  
2012/06/06 01:27:40 [debug] 15621#0: \*5 http upstream request:  
“/service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset”  
2012/06/06 01:27:40 [debug] 15621#0: \*5 http upstream send request  
handler  
2012/06/06 01:27:40 [debug] 15621#0: \*5 http upstream send request  
2012/06/06 01:27:44 [debug] 15621#0: \*5 http upstream request:  
“/service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset”  
… … \<— tens of similar log entires  
2012/06/06 01:28:19 [debug] 15621#0: \*5 http upstream send request  
handler  
2012/06/06 01:28:19 [debug] 15621#0: \*5 http upstream send request  
2012/06/06 01:28:22 [debug] 15621#0: \*5 http upstream request:  
“/service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset”  
2012/06/06 01:28:22 [debug] 15621#0: \*5 http upstream send request  
handler  
2012/06/06 01:28:22 [debug] 15621#0: \*5 http upstream send request  
2012/06/06 01:28:22 [debug] 15621#0: \*5 http upstream request:  
“/service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset”  
2012/06/06 01:28:22 [debug] 15621#0: \*5 http upstream process header  
2012/06/06 01:28:22 [debug] 15621#0: \*5 http proxy status 200 “200 OK”  
2012/06/06 01:28:22 [debug] 15621#0: \*5 http proxy header: “Date: Tue,  
05 Jun 2012 17:27:37 GMT”  
2012/06/06 01:28:22 [debug] 15621#0: \*5 http proxy header:  
“Content-Type: text/html; charset=utf-8”  
2012/06/06 01:28:22 [debug] 15621#0: \*5 http proxy header: “Connection:  
close”  
2012/06/06 01:28:22 [debug] 15621#0: \*5 http proxy header done  
2012/06/06 01:28:22 [debug] 15621#0: \*5 HTTP/1.1 200 OK

Server: nginx

Date: Tue, 05 Jun 2012 17:28:22 GMT

Content-Type: text/html; charset=utf-8

Transfer-Encoding: chunked

Connection: keep-alive

2012/06/06 01:28:22 [debug] 15621#0: \*5 http write filter: l:0 f:0  
s:163  
2012/06/06 01:28:22 [debug] 15621#0: \*5 http cacheable: 0  
2012/06/06 01:28:22 [debug] 15621#0: \*5 http upstream process upstream  
2012/06/06 01:28:23 [debug] 15621#0: \*5 http upstream request:  
“/service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset”  
2012/06/06 01:28:23 [debug] 15621#0: \*5 http upstream send request  
handler  
2012/06/06 01:28:57 [debug] 15621#0: \*5 http upstream request:  
“/service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset”  
2012/06/06 01:28:57 [debug] 15621#0: \*5 http upstream process upstream  
2012/06/06 01:28:57 [debug] 15621#0: \*5 http output filter  
“/service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset”  
2012/06/06 01:28:57 [debug] 15621#0: \*5 http copy filter:  
“/service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset”  
2012/06/06 01:28:57 [debug] 15621#0: \*5 http postpone filter  
“/service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset”  
0000000001D2A388  
2012/06/06 01:28:57 [debug] 15621#0: \*5 http chunk: 22  
2012/06/06 01:28:57 [debug] 15621#0: \*5 http write filter: l:0 f:0  
s:191  
2012/06/06 01:28:57 [debug] 15621#0: \*5 http copy filter: 0  
“/service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset”  
2012/06/06 01:28:57 [debug] 15621#0: \*5 http upstream exit:  
0000000000000000  
2012/06/06 01:28:57 [debug] 15621#0: \*5 finalize http upstream request:  
0  
2012/06/06 01:28:57 [debug] 15621#0: \*5 finalize http proxy request  
2012/06/06 01:28:57 [debug] 15621#0: \*5 free rr peer 1 0  
2012/06/06 01:28:57 [debug] 15621#0: \*5 close http upstream connection:  
20  
2012/06/06 01:28:57 [debug] 15621#0: \*5 http upstream temp fd: -1  
2012/06/06 01:28:57 [debug] 15621#0: \*5 http output filter  
“/service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset”  
2012/06/06 01:28:57 [debug] 15621#0: \*5 http copy filter:  
“/service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset”  
2012/06/06 01:28:57 [debug] 15621#0: \*5 http postpone filter  
“/service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset”  
00007FFF51B162A0  
2012/06/06 01:28:57 [debug] 15621#0: \*5 http chunk: 0  
2012/06/06 01:28:57 [debug] 15621#0: \*5 http write filter: l:1 f:0  
s:196  
2012/06/06 01:28:57 [debug] 15621#0: \*5 http write filter limit 0  
2012/06/06 01:28:57 [debug] 15621#0: \*5 http write filter  
0000000000000000  
2012/06/06 01:28:57 [debug] 15621#0: \*5 http copy filter: 0  
“/service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset”  
2012/06/06 01:28:57 [debug] 15621#0: \*5 http finalize request: 0,  
“/service/home/removed\_email\_address@domain.invalid/?fmt=tgz&resolve=reset” a:1, c:1  
2012/06/06 01:28:57 [debug] 15621#0: \*5 set http keepalive handler  
2012/06/06 01:28:57 [debug] 15621#0: \*5 http close request  
2012/06/06 01:28:57 [debug] 15621#0: \*5 http log handler  
2012/06/06 01:28:57 [debug] 15621#0: \*5 hc free: 0000000000000000 0  
2012/06/06 01:28:57 [debug] 15621#0: \*5 hc busy: 0000000000000000 0  
2012/06/06 01:28:57 [debug] 15621#0: \*5 tcp\_nodelay  
2012/06/06 01:28:57 [debug] 15621#0: \*5 http keepalive handler  
2012/06/06 01:28:57 [debug] 15621#0: \*5 http keepalive handler  
2012/06/06 01:28:57 [info] 15621#0: \*5 client 10.112.117.117 closed  
keepalive connection  
2012/06/06 01:28:57 [debug] 15621#0: \*5 close http connection: 14

Posted at Nginx Forum:

> **[Re: Can't upload big files via nginx as reverse proxy](https://forum.nginx.org/read.php?2,227175,227182#msg-227182)**
>
> Hey. In my env, the layout is: client \<--\> nginx \<--\> jetty In the client, there is a \<input type=file\> control. I tried to upload a file with size of 3.7MB. In the client request, the content type is...

---

<div class="post-metadata">

**Author:** ![speedfirst](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/e19adc/32.png) [@speedfirst](https://www.ruby-forum.com/u/speedfirst)\
**Post date:** [March 24, 2014, 7:17pm UTC](https://www.ruby-forum.com/t/cant-upload-big-files-via-nginx-as-reverse-proxy/220287/7 "2014-03-24T19:17:22Z")

</div>

Hi, everybody.

Any solutions to this issue?

Thx

Posted at Nginx Forum:

> **[Re: Can't upload big files via nginx as reverse proxy](https://forum.nginx.org/read.php?2,227175,248638#msg-248638)**
>
> Hey. In my env, the layout is: client \<--\> nginx \<--\> jetty In the client, there is a \<input type=file\> control. I tried to upload a file with size of 3.7MB. In the client request, the content type is...

---

<div class="post-metadata">

**Author:** ![speedfirst](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/e19adc/32.png) [@speedfirst](https://www.ruby-forum.com/u/speedfirst)\
**Post date:** [June 5, 2012, 1:27pm UTC](https://www.ruby-forum.com/t/cant-upload-big-files-via-nginx-as-reverse-proxy/220287/8 "2012-06-05T13:27:09Z")

</div>

> On the other hand, it looks like sending of the request is still  
> in progress, and upstream server replies before the request was  
> completely sent. It might indicate it just doesn’t wait long  
> enough, and the problem is in the backend (and slow connectivity  
> to the backend).

> I don’t see any pause in request sending you’ve claimed in your  
> initial message.

> On the other hand, here is ~ 30s pause you’ve probably talked  
> about. It might indicate that upstream tries to send headers  
> before “receiving and interpreting a request message” (as per HTTP  
> RFC2616 it should do it “after”), which confuses nginx and makes  
> it to think further body bytes aren’t needed.

> understand the real problem.

Yes, I agree and also notice where the real problem is. I just created a  
fake backend (which simply receives the uploaded data and writes into  
disk), nginx correctly pass all the data to it.

Let me hack the backend code to see what’s wrong. Will update if I found  
something new.

Thanks for your inspired comments 🙂

Posted at Nginx Forum:  
[http://forum.nginx.org/read.php?2,227175,227190#msg-227190](http://forum.nginx.org/read.php?2,227175,227190#msg-227190)