Custom 413 error pages when client_max_body_size exceeded
Frank Swasey
frank.swasey at gmail.com
Thu Oct 20 20:22:52 UTC 2022
You do realize you redirected to <name>.htm and specified <page>.html in
the location, right?
On Thu, Oct 20, 2022 at 14:02 Dan G. Switzer, II <dan.switzer at givainc.com>
wrote:
> Sergey,
>
> Thanks for taking the time to respond. That's not working for me. I tried
> the following:
>
>
> server {
> listen 80;
>
> client_max_body_size 10k;
>
> error_page 403 =404 /404_status_code.htm;
> error_page 404 =404 /404_status_code.htm;
> error_page 413 =413 /413_status_code.htm;
>
> location /upload {
> dav_methods PUT;
> create_full_put_path on;
> dav_access group:rw all:r;
> }
>
> location = /404_status_code.html {
> internal;
> root /path/to/my/custom/errors;
> }
>
> location = /413_status_code.html {
> internal;
> root /path/to/my/custom/errors;
> }
> }
>
>
> The 404 works fine, but sending more than 10k to the request still returns
> the default nginx page.
>
> If I curl to a non-existent URL, I get the custom 404. The 413 doesn't. If
> I remove the "internal" command, I can view the /413_status_code.html file
> just fine.
>
> Is there a good way I can debug/troubleshoot why it might not be working?
>
> It really seems like it might be a bug with the version of nginx that
> CentOS 7 is installing.
>
> -Dan
>
> On 10/20/2022 11:05 AM, Sergey A. Osokin wrote:
>
> Hi Dan,
>
> thanks for the report.
>
> On Thu, Oct 20, 2022 at 09:04:31AM -0400, Dan G. Switzer, II wrote:
>
> I'm using nginx/1.20.1 under CentOS Linux release 7.9.2009 (Core) and I
> cannot get a custom error page to show when the client_max_body_size
> limit has been exceeded. The browser will only return the default nginx
> error page.
>
> [...]
>
>
> However, if I change the code to:
>
>
> error_page 404 =404 /404_status_code.htm;
> error_page 403 =404 /404_status_code.htm;
> error_page 413 =413 /413_request_too_large.htm;
>
> location /404_status_code.htm {
> internal;
> root /path/to/my/custom/errors/;
> add_header X-Original-URL "$scheme://$http_host$request_uri" always;
> }
>
> location /413_request_too_large.htm {
> internal;
> root /path/to/my/custom/errors/;
> add_header X-Original-URL "$scheme://$http_host$request_uri" always;
> }
>
> When I try to upload a file larger than my client_max_body_size setting,
> I still get the default error page. I've tried a lot of different
> variations of the code, but nothing seems to work.
>
>
> Is there something special that needs to be done to implement a custom
> error page for a 413 status code? Or is there perhaps a regression that
> broke this from working?
>
> Here's the configuration that works here:
>
> server {
> listen 80;
>
> client_max_body_size 10k;
>
> error_page 403 =404 /404_status_code.html;
> error_page 404 =404 /404_status_code.html;
> error_page 413 =413 /413_status_code.html;
>
> location /upload {
> dav_methods PUT;
> create_full_put_path on;
> dav_access group:rw all:r;
> }
>
> location = /413_status_code.html {
> internal;
> root /usr/local/www/nginx;
> }
> }
>
> % dd if=/dev/zero of=11k bs=1k count=11
> 11+0 records in
> 11+0 records out
> 11264 bytes transferred in 0.000075 secs (150232738 bytes/sec)
>
> % cat /usr/local/www/nginx/413_status_code.html
> <html>
> <body>
> here's the 413 error
> </body>
> </html>
>
> % curl -T 11k https://url.emailprotection.link/?bBgKrp4MmqsBU6w4TjxZ9_JqJd9V0NDmTOHlOJxvE4o6VBzwgW7OP1tEufUK7BpJqJXzp1a-EKqVvPqu_3UYV0A~~
> <html>
> <body>
> here's the 413 error
> </body>
> </html>
>
> Thank you.
>
>
>
> --
> Dan G. Switzer, II
> Giva, Inc.
> Email: dan.switzer at givainc.com
> Web Site: http://www.givainc.com
>
> See Our Customer Successes http://www.givainc.com/customers-casestudies.htm
>
> _______________________________________________
> nginx mailing list -- nginx at nginx.org
> To unsubscribe send an email to nginx-leave at nginx.org
>
--
I am not young enough to know everything. - Oscar Wilde (1854-1900)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20221020/11fc1da9/attachment.htm>
More information about the nginx
mailing list