Custom 413 error pages when client_max_body_size exceeded

[Dan G. Switzer, II]

Sorry, that was a typo from the tweak to the real file names. The file 
extensions matched in my test and I got the custom 404 error page.

On 10/20/2022 4:22 PM, Frank Swasey wrote:
> 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 11khttps://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  <https://url.emailprotection.link/?bhjBYMqDY4Ztp4avwgwh-mfk6NkHsmC1wbas7UBcaAeFD3u9uFgGS2UeqToAsqzSIdZftmRn6Fqh9GTxM-n924A~~>
>
>     See Our Customer Successes
>     http://www.givainc.com/customers-casestudies.htm  <https://url.emailprotection.link/?bQFudat7_sfP7dfaw5blL1Fd_nJ2I93M6XjiAQOSV9FDvdHniCzGbxIo47iEiDZACk_KRZBygM1CmQRz78brGlxzQq_m40Fkq7z6b8bOipFBJSIFaa9-rofFRkLRLhYPE>
>
>     _______________________________________________
>     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)
>
> _______________________________________________
> nginx mailing list --nginx at nginx.org
> To unsubscribe send an email tonginx-leave at nginx.org

-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20221020/f1266173/attachment.htm>