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

04ad1ab3d96f873cc3c7a6ccf0328662?d=identicon&s=25 Michael Nachbaur (Guest)
on 2009-06-04 01:32
(Received via mailing list)
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. :-)
2974d09ac2541e892966b762aad84943?d=identicon&s=25 pvdb (Guest)
on 2009-09-01 10:38
(Received via mailing list)
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!!!  ;-)

Many thanks in advance!

Peter

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,2620,5422#msg-5422
61e47e92bf539414f174fdd8b97a8f2a?d=identicon&s=25 Peter Vandenberk (Guest)
on 2009-09-01 10:49
(Received via mailing list)
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:
> http://forum.nginx.org/read.php?2,2620,5422#msg-5422

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
5640e332954fc0006aea97a155ce0afd?d=identicon&s=25 Igor Sysoev (Guest)
on 2009-09-01 11:34
(Received via mailing list)
Attachment: patch.413 (519 Bytes)
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.
61e47e92bf539414f174fdd8b97a8f2a?d=identicon&s=25 Peter Vandenberk (Guest)
on 2009-09-01 12:34
(Received via mailing list)
Hi Igor,

Igor Sysoev <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 Sysoev <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;
      }
5640e332954fc0006aea97a155ce0afd?d=identicon&s=25 Igor Sysoev (Guest)
on 2009-09-01 13:11
(Received via mailing list)
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 Sysoev <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.
2974d09ac2541e892966b762aad84943?d=identicon&s=25 estebistec (Guest)
on 2010-06-18 18:49
(Received via mailing list)
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.

[code]
error_page 413 /413.html;

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

location /test413 {
    return 413;
}
[/code]

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,2620,99990#msg-99990
A8108a0961c6087c43cda32c8616dcba?d=identicon&s=25 Maxim Dounin (Guest)
on 2010-06-21 01:20
(Received via mailing list)
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 Dounin
2974d09ac2541e892966b762aad84943?d=identicon&s=25 estebistec (Guest)
on 2010-06-21 15:20
(Received via mailing list)
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 Dounin Wrote:
-------------------------------------------------------
> stable in
> show some default error (browser's one).
>
> Maxim Dounin
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://nginx.org/mailman/listinfo/nginx

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,2620,100805#msg-100805
A8108a0961c6087c43cda32c8616dcba?d=identicon&s=25 Maxim Dounin (Guest)
on 2010-06-21 18:21
(Received via mailing list)
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 Dounin
8a99b09b09b7e3933aa0e36285a34419?d=identicon&s=25 Steven Cummings (Guest)
on 2010-06-22 03:46
(Received via mailing list)
Sure thing. I'll get all the info together soon. Thanks!
--
Steven
2974d09ac2541e892966b762aad84943?d=identicon&s=25 estebistec (Guest)
on 2010-06-24 00:50
(Received via mailing list)
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:
http://forum.nginx.org/read.php?2,2620,101752#msg-101752
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.