Forum: NGINX client_max_body_size and 100 Continue/413 Request Entity Too Large

Posted by Joe Shaw (Guest)
on 2012-11-16 21:59
(Received via mailing list)
Hi,

I have a web app that accepts uploads from clients.  We have a 
relatively
high client_max_body_size set, and I'd like for clients to be able to be
quickly rejected if they intend to upload files larger than the max body
size.  The "Expect: 100-continue" header seems ideally suited for this.

However, when I try to upload a large file with curl (which uses the 
Expect
header), nginx responds with "100 Continue" instead of "413 Request 
Entity
Too Large":

> POST /test HTTP/1.1
> User-Agent: curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0
OpenSSL/0.9.8r zlib/1.2.5
> Host: example.com
> Accept: */*
> Content-Length: 454327718
> Content-Type: application/octet-stream
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
< HTTP/1.1 413 Request Entity Too Large
< Server: nginx/1.2.0
< Content-Type: text/html; charset=utf-8
< Date: Fri, 16 Nov 2012 20:40:24 GMT
< Connection: Keep-Alive
< Content-Length: 198

I would have expected nginx to return the 413 error instead of the 100
status code.  As it is now, the client will continue to upload its data
because it got the go ahead via the 100 status code.

Is this a bug (or unimplemented feature) in nginx?  Is there any way 
around
this?  As you can see from the response, I'm using nginx 1.2.0, which I
realize isn't the latest, but I couldn't find anything related to this 
in
the CHANGES file.

Thanks,
Joe
Posted by Maxim Dounin (Guest)
on 2012-11-17 22:44
(Received via mailing list)
Hello!

On Fri, Nov 16, 2012 at 03:58:51PM -0500, Joe Shaw wrote:

>
> < HTTP/1.1 413 Request Entity Too Large
> Is this a bug (or unimplemented feature) in nginx?  Is there any way around
> this?  As you can see from the response, I'm using nginx 1.2.0, which I
> realize isn't the latest, but I couldn't find anything related to this in
> the CHANGES file.

As of now nginx is only capable of recognizing "Expect:
100-continue" and returning "100 Continue" response to avoid
upload delays.  It's not able to recognize it is going to return
fatal error and isn't able to avoid sending "100 Continue" in this
case.

--
Maxim Dounin
http://nginx.com/support.html
Posted by Igor Sysoev (Guest)
on 2012-11-18 11:03
Attachment: patch.expect.txt (543 Bytes)
(Received via mailing list)
On Nov 17, 2012, at 0:58 , Joe Shaw wrote:

> > Content-Length: 454327718
>
> I would have expected nginx to return the 413 error instead of the 100 status 
code.  As it is now, the client will continue to upload its data because it got 
the go ahead via the 100 status code.
>
> Is this a bug (or unimplemented feature) in nginx?  Is there any way around 
this?  As you can see from the response, I'm using nginx 1.2.0, which I realize 
isn't the latest, but I couldn't find anything related to this in the CHANGES 
file.


The attached patch should fix the bug.
Please log in before posting. Registration is free and takes only a minute.
Existing account (Switch to SSL-encrypted connection)
NEW: Do you have a Google/GoogleMail or Yahoo account? No registration required!
Log in with Google account | Log in with Yahoo account
No account? Register here.