Welcome! Log In Create A New Profile


File upload with a 500 response

June 18, 2010 07:04AM

I'm seeing some unusual behaviour in one specific client interaction with nginx and wonder if anyone has seen anything similar or can offer any explanation as to why this might be happening. I'm running nginx version 0.7.65.

From a curl command line I'm issuing a POST request to nginx over https. The POST request has a content-type of multipart/form-data and I'm using it to send some data and upload a file of just under 1Mb.

nginx is being used as a proxy for upstream web servers built with mochiweb. Under normal conditions, everything works fine. The file is uploaded successfully and stored in the back-end database. During testing I'm deliberately causing a 500 Internal Server Error to be returned by the upstream web servers to nginx, and this is where I'm seeing some unusual behaviour.

The 500 status code is indeed returned but there is something strange going on with the client/nginx/upstream web server interaction. The whole interaction takes about 10 seconds. Curl rapidly receives the response headers with the 500 status code but then waits. It never receives the response body sent by the client - in this case the content-length is only 200 bytes and the client receives this length in the Content-Length response header. Curl reports an error code 18, meaning that it expected a response body of (in this case) 200 bytes but received less than this (zero in fact as curl reports that the transfer was closed with 200 bytes remaining to read).

If I reduce the size of the file uploaded by this method, the problem disappears and curl receives the entire response body just fine. Also, everything is just fine with other web services where I deliberately introduce a 500 response code. It's just for the file upload of a significantly sized file (about 1Mb) that I see this behaviour.

I know that nginx will receive the file in its entirety and store it in a temporary location on the server before it talks to the upstream web server, and it clearly is talking to the upstream web server so it seems it has received the file completely before it attempts to return the 500 code.

I've also bypassed nginx and let curl talk directly to the upstream web server. In this case, the 500 response is received rapidly and in full (body intact).

Here's the interaction as recorded by Curl:

- User-Agent: curl/7.19.5 (i486-pc-linux-gnu) libcurl/7.19.5 OpenSSL/0.9.8g zlib/ libidn/1.15
- Host:
- Accept: */*
- Content-Length: 775038
- Expect: 100-continue
- Content-Type: multipart/form-data; boundary=----------------------------5b3896de4770
+ HTTP/1.1 100 Continue
+ HTTP/1.1 500 Internal Server Error
+ Server: nginx/0.7.65
+ Date: Fri, 18 Jun 2010 10:31:28 GMT
+ Content-Type: text/html
+ Connection: keep-alive
+ Content-Length: 200
* SSLv3, TLS alert, Client hello (1):
* transfer closed with 200 bytes remaining to read
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
curl: (18) transfer closed with 200 bytes remaining to read

The nginx logs show that a 500 response code was indeed returned, but the body's content-length was zero.

This isn't a showstopper, but it's behaviour I can't explain. Can anyone offer any ideas as to why I might be seeing this?

Subject Author Posted

File upload with a 500 response

woodsmar June 18, 2010 07:04AM

Re: File upload with a 500 response

Maxim Dounin June 18, 2010 08:06AM

Re: File upload with a 500 response

woodsmar June 18, 2010 10:25AM

Re: File upload with a 500 response

Maxim Dounin June 21, 2010 08:14AM

Re: File upload with a 500 response

woodsmar June 21, 2010 08:23AM

Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 136
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready