Bug: custom error_page doesn't work for HTTP 413 (content too large)

After a few hours of digging through the nginx code, I think I’ve
discovered the nature of the bug, but I still don’t know how to fix it
just yet. I’m using the 3rd-party upload module to handle my uploads,
which are then sent along to a fastcgi process.

The problem I’m having is I can’t seem to set a custom error page for
HTTP 413 errors. If I issue a file upload to an nginx url and it
exceeds the maximum size set in my configuration, I want the custom
error page to show. Instead I get the nginx default.

error_page 413 /err/413.html

when I upload will give me something like this in my error log:

2009/06/03 23:08:06 [error] 19180#0: *163 client intended to send too
large body: 995365 bytes, client: 192.168.98.223, server: localhost,
request: “POST /attach HTTP/1.1”, host: “localhost:10443”, referrer:
"https://localhost:10443/attach
"
2009/06/03 23:08:06 [error] 19180#0: *163 client intended to send too
large body: 995365 bytes, client: 192.168.98.223, server: localhost,
request: “POST /attach HTTP/1.1”, host: “localhost:10443”, referrer:
"https://localhost:10443/attach
"

When I pointed the error page at an invalid location (error_page 413
@bad_location) I got this instead:

2009/06/03 23:06:31 [error] 11885#0: *153 client intended to send too
large body: 995365 bytes, client: 192.168.98.223, server: localhost,
request: “POST /attach HTTP/1.1”, host: “localhost:10443”, referrer:
"https://localhost:10443/attach
"
2009/06/03 23:06:31 [error] 11885#0: *153 could not find named
location “@bad_location”, client: 192.168.98.223, server: localhost,
request: “POST /attach HTTP/1.1”, host: “localhost:10443”, referrer:
"https://localhost:10443/attach
"

So what I think is happening is the initial request is made, which
eventually throws a NGX_HTTP_REQUEST_ENTITY_TOO_LARGE error, resulting
in the error page handler to run. It tries cleaning up the request
and resets it to an internal request for /err/413.html, but I think it
isn’t cleaning everything up well enough. So when the error page tries
to load, it notices that the content length of the request is still
too large, and throws an error as well.

Does anyone have any idea how to fix this, or would like to submit a
patch? I’m going to try my best to fix the code, and if I can I’ll
send a patch in to the mailing list. But my C skills aren’t that
solid, and I’m unfamiliar with the nginx codebase.

Thank you, and I hope someone has a magic-bullet solution for this. :slight_smile:

Hi all,

Michael Nachbaur wrote:

I am dealing with the same requirement (implement a custom 413 nginx
error page) and am banging my head against the wall for the same reason
that Mike describes in his original post.

I hope that by posting a reply I can rekindle this thread enough to get
to the bottom of this bug / issue so that I’m able to implement the
custom 413 error page our users are craving!!! :wink:

Many thanks in advance!

Peter

Posted at Nginx Forum:

On Mon, Aug 31, 2009 at 03:38:44PM +0000, Peter Vandenberk wrote:

Any ideas? Many thanks in advance,

The attached patch should fix the bug.

However, browsers usually show the 413 error page only after they have
sent
a whole request body. Therefore on slow connection and with large body
browsers will show some network error or “this page cannot be displayed”
page.

Hi Igor,

Igor S. <is@…> writes:

The attached patch should fix the bug.

Thanks for the quick reply to my question, and for taking the time
to supply a patch… much appreciated!

The patch works like a charm… thanks for that! I forgot to mention
that we are running the “legacy” 0.6.xx version of nginx, so I have
attached a slightly modified version of your patch with the correct
diff context (esp. line numbers) for that version of the code base.

Igor S. <is@…> writes:

However, browsers usually show the 413 error page only after they have sent
a whole request body. Therefore on slow connection and with large body
browsers will show some network error or “this page cannot be displayed” page.

Yes, thanks for the heads up… some of our users have indeed reported
that behaviour to us as well, but quite a few also get a proper 413
response,
which is why we are so eager to implement a custom 413 error page.

Thanks again for your time and the patch!

Peter

===

*** src/http/ngx_http_core_module.orig 2009-08-31 18:10:46.000000000
+0100
— src/http/ngx_http_core_module.c 2009-08-31 18:11:26.000000000 +0100


*** 859,864 ****
— 859,865 ----
“client intended to send too large body: %O
bytes”,
r->headers_in.content_length_n);

  •     (void) ngx_http_discard_request_body(r);
        ngx_http_finalize_request(r, 
    

NGX_HTTP_REQUEST_ENTITY_TOO_LARGE);
return NGX_OK;
}

pvdb <nginx-forum@…> writes:

I am dealing with the same requirement (implement a custom
413 nginx error page) and am banging my head against the
wall for the same reason that Mike describes in his original post.

Posted at Nginx Forum:
Re: Bug: custom error_page doesn't work for HTTP 413 (content too large)

It appears that the cross-posting between the two mailing lists
has truncated my original post…

Here’s a bit more context from Mike’s original post:

The problem I’m having is I can’t seem to set a custom error page for
HTTP 413 errors. If I issue a file upload to an nginx url and it
exceeds the maximum size set in my configuration, I want the custom
error page to show. Instead I get the nginx default.

error_page 413 /err/413.html

when I upload will give me something like this in my error log: …

Basically I’m having the same issue, and no matter how many different
variations of my nginx.conf I try, I can not get it to serve my custom
413.html error page, but always serves the default nginx 413 one.

Here’s the relevant snippet from my nging.conf file:

    error_page  413              /413.html;
    location = /413.html {
        root   /usr/local/nginx/html;
    }

Any ideas? Many thanks in advance,

Peter Vandenberk

Has the patch been worked into a release? We are still experiencing this
bug on version 0.7.65.

Also, we noticed an interesting wrinkle. If we add a URI that explicitly
returns 413, we can get our error page by hitting that URI.

error_page 413 /413.html;

location /413.html {
    alias /etc/nginx/entity_body_too_large.html;
}

location /test413 {
    return 413;
}

Posted at Nginx Forum:

Hello!

On Fri, Jun 18, 2010 at 12:48:24PM -0400, estebistec wrote:

Has the patch been worked into a release? We are still experiencing this
bug on version 0.7.65.

This patch was introduced in 0.8.14 and merged to stable in
0.7.63.

Are you sure you are experiencing this bug, i.e. you see
nginx’s default error page?

The main problem with 413 errors is that browsers doesn’t show
them. Instead they consider connection abnormally terminated and
show some default error (browser’s one).

Maxim D.

Yeah, I’m fairly certain it’s nginx’s page. It’s a plain page with just
“413 Request Entity Too Large” (an h1) and below that and an hr,
“nginx”. I would assume the browser’s own page would not say “nginx”.
I’m using Chrome, btw.

Maxim D. Wrote:

stable in
show some default error (browser’s one).

Maxim D.


nginx mailing list
[email protected]
nginx Info Page

Posted at Nginx Forum:

Hello!

On Mon, Jun 21, 2010 at 09:19:33AM -0400, estebistec wrote:

Yeah, I’m fairly certain it’s nginx’s page. It’s a plain page with just
“413 Request Entity Too Large” (an h1) and below that and an hr,
“nginx”. I would assume the browser’s own page would not say “nginx”.
I’m using Chrome, btw.

Ok, so please follow usual debugging instructions (see
http://wiki.nginx.org/NginxDebugging).

I.e. please provide:

  1. nginx -V output;

  2. config;

  3. debug log.

Maxim D.

On Mon, Aug 31, 2009 at 05:25:45PM +0000, Peter Vandenberk wrote:

attached a slightly modified version of your patch with the correct
diff context (esp. line numbers) for that version of the code base.

Yes, the patch should work for 0.6.x too.

Igor S. <is@…> writes:

However, browsers usually show the 413 error page only after they have sent
a whole request body. Therefore on slow connection and with large body
browsers will show some network error or “this page cannot be displayed” page.

Yes, thanks for the heads up… some of our users have indeed reported
that behaviour to us as well, but quite a few also get a proper 413 response,
which is why we are so eager to implement a custom 413 error page.

You may increase

lingering_time 30s; # default
lingering_timeout 5s; # default

lingering_time sets how long nginx will read discarded body before
closing
connection. lingering_timeout is timeout between two read() operation.
If client did not send anything during this time, then nginx closes
connection.

Sure thing. I’ll get all the info together soon. Thanks!

Steven

I just discovered that there was more to our stack than I originally
knew. So we have nginx instances layered and I didn’t realize I was
hitting another before getting to the one I had configured. Let me
verify this but otherwise assume there’s no problem. I’ll report back if
the problem still exists, but I’m thinking not. Sorry for imposing my
confusions here.

Posted at Nginx Forum: