<!-- NOTICE: This Issue tracker is for the GitLab Helm chart, not the GitLab Rails application. Support: Please do not raise support issues for GitLab.com on this tracker. See https://about.gitlab.com/support/ --> ## Summary Original issue: https://gitlab.com/gitlab-org/quality/gitlab-environment-toolkit-configs/staging-ref/-/issues/161 NGINX `proxy_request_buffering` is enabled by default, but it breaks a functionality of endpoints responsible for transferring git data via SSH protocol. Requests from GitLab-Shell to Workhorse hang and that breaks `git fetch/git push` commands. In issue https://gitlab.com/gitlab-org/gitlab/-/issues/466160 I've excluded two more endpoints from `proxy_request_buffering` list [in GDK](https://gitlab.com/gitlab-org/gitlab-development-kit/-/merge_requests/3757) and [Omnibus](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/7713) But these changes don't affect Helm Chart deployments. ## Goal Define a way to exclude a list of endpoints from NGINX `proxy_request_buffering` configuration for Helm Chart deployments. **More details** `@WarheadsSE` comments: > > The request from GitLab-Shell to Workhorse was hanging. After investigation I discovered the root cause of this problem. > > In most CNH, shell is in :kubernetes: In the :kubernetes: deployment via Helm, Shell talks directly to to the Webservice's Service object, and does not go through NGINX. > As this primarily affects Shells' HTTP calls to Workhorse ... We'd need this to somehow be defined in the Webservices Ingress object. > (Though again, you 'd have to have a large, distributed fleet that could not talk directly) > Currently we don't apply any of these types of configuration, apparently. Out of the box, it is fully disabled in Ingress NGINX (which is what we use) https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#proxy-buffering [Slack](https://gitlab.slack.com/archives/C1FCTU4BE/p1720702996421549)