Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Proposal]: Add large_client_header_buffers,client_header_buffer_size as configmap keys #6857

Open
niruse opened this issue Nov 24, 2024 · 3 comments
Labels
needs triage An issue that needs to be triaged proposal An issue that proposes a feature request

Comments

@niruse
Copy link

niruse commented Nov 24, 2024

I’ve opened a second issue case here as well:
nginxinc/nginx-ingress-helm-operator#426

Version

3.6.1

What Kubernetes platforms are you running on?

Openshift

Steps to reproduce

Bug Report: 400 Error When Request URL/Header Is Too Long

Image

Describe the Bug

We couldn't find the proper setting to add to my configmap for updating large_client_header_buffers and client_header_buffer_size.
We could publish different configurations based on the article, but those two are not working.


To Reproduce

Steps to reproduce the behavior:

  1. Deploy the NGINX operator.
  2. Deploy the ConfigMap (CM) with the following configuration:
    apiVersion: v1
    data:
      client-header-buffer-size: 512k
      client-max-body-size: 100m
      keep-alive-requests: "10000"
      large-client-header-buffers: 4 64k
  3. Run the following command on one of the nodes:
    oc exec -it ngx1-nginx-ingress-controller-77dd6577b8-wfx89 -n nginx-ingress -- grep -r "client_header_buffer_size" /etc/nginx/
    • The configuration contains client_header_buffer_size changed to the new size.
  4. Run the same command with large_client_header_buffers:
    oc exec -it ngx1-nginx-ingress-controller-77dd6577b8-wfx89 -n nginx-ingress -- grep -r "large_client_header_buffers" /etc/nginx/
    • Issue: The configuration does not reflect the changes for large_client_header_buffers.

Expected Behavior

You should see the updated configuration in the NGINX configuration.


Manual Solution

When I updated the large_client_header_buffers and client_header_buffer_size manually in the nginx.conf file, the error 400 was resolved, and I gained access to the web application.


Environment

  • Version of the NGINX Ingress Operator: 2.3.1
  • Version of the Ingress Controller: 3.6.1
  • Version of Kubernetes: v1.27.16+e826056
  • Kubernetes Platform: OpenShift
  • Using NGINX or NGINX Plug: Using NGINX
  • Client Version: 4.14.18
  • Kustomize Version: v5.0.1
  • Server Version: 4.14.35

@niruse niruse added bug An issue reporting a potential bug needs triage An issue that needs to be triaged labels Nov 24, 2024
Copy link

Hi @niruse thanks for reporting!

Be sure to check out the docs and the Contributing Guidelines while you wait for a human to take a look at this 🙂

Cheers!

@j1m-ryan
Copy link
Member

Hi @niruse,
large-client-header-buffers and client-header-buffer-size are not supported config map keys. You can see a list of supported keys here.

The way to do this at the moment is to use a http or server snippet in the configmap.

I will change this issue from a bug to a proposal to add these keys as first class config map keys.

@j1m-ryan j1m-ryan added proposal An issue that proposes a feature request and removed bug An issue reporting a potential bug labels Nov 25, 2024
@j1m-ryan j1m-ryan changed the title [Bug]: Can't update two configuration through configmap - large_client_header_buffers,client_header_buffer_size [Proposal]: Add large_client_header_buffers,client_header_buffer_size as configmap keys Nov 25, 2024
@niruse
Copy link
Author

niruse commented Nov 25, 2024

Hi Ryan,
Thank you for your response.
Could you provide an example of how to add it as snippets or HTTP in configmap?
We’ve tried different methods without success.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs triage An issue that needs to be triaged proposal An issue that proposes a feature request
Projects
Status: Todo ☑
Development

No branches or pull requests

2 participants