You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
The client-max-body-size set on a virtual server upstream is not enforced when the following is true:
(1) the directive is set in an internal location block, and
(2) the value is greater than the default value of 1m for client_max_body_size.
To Reproduce
Steps to reproduce the behavior:
Deploy the ingress controller
Follow the Advanced Routing example but add client_max_body_size to the tea-post upstream. Set it to "2m".
Expected behavior
The client-max-body-size for the tea-post upstream should be enforced instead of the default client-max-body-size.
Your environment
Version of the Ingress Controller - NGINX Ingress Controller Version=3.5.2 Commit=90d40829ca0b92e4a8ebcc36415c220e72da7405
Version of Kubernetes: 1.30
Kubernetes platform (e.g. Mini-kube or GCP): minikube
Using NGINX or NGINX Plus: nginx
Additional context
This bug was initially found in NGINX Gateway Fabric and may apply to more than just the client_max_body_size directive.
The underlying issue is that nginx checks the body size of the request twice -- once in the external location block /tea and again in the internal location block that actually proxies the request to tea-post. If the request body exceeds the max body size in the external location block, a 413 is returned without nginx ever redirecting the request to the internal location block with the greater client_max_body_size. Even if client_max_body_size is not specified in the external location block, nginx will still check that the request body is under the default value of "1m". This is why this bug only applies when the internal client_max_body_size is greater than "1m".
Describe the bug
The
client-max-body-size
set on a virtual server upstream is not enforced when the following is true:(1) the directive is set in an internal location block, and
(2) the value is greater than the default value of
1m
forclient_max_body_size
.To Reproduce
Steps to reproduce the behavior:
but add
client_max_body_size
to thetea-post
upstream. Set it to "2m"./tea
with a payload > 1mExpected behavior
The client-max-body-size for the tea-post upstream should be enforced instead of the default client-max-body-size.
Your environment
NGINX Ingress Controller Version=3.5.2 Commit=90d40829ca0b92e4a8ebcc36415c220e72da7405
Additional context
This bug was initially found in NGINX Gateway Fabric and may apply to more than just the
client_max_body_size
directive.The underlying issue is that nginx checks the body size of the request twice -- once in the external location block
/tea
and again in the internal location block that actually proxies the request totea-post
. If the request body exceeds the max body size in the external location block, a 413 is returned without nginx ever redirecting the request to the internal location block with the greaterclient_max_body_size
. Even ifclient_max_body_size
is not specified in the external location block, nginx will still check that the request body is under the default value of "1m". This is why this bug only applies when the internalclient_max_body_size
is greater than "1m".Related: nginxinc/nginx-gateway-fabric#2079 and nginxinc/nginx-gateway-fabric#2105
The text was updated successfully, but these errors were encountered: