Expose nginx large_client_header_buffers as a BOSH property on cloud_controller_ng

Open Beginner friendly
#669 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
76/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Quiet
Tech stack
nginx

Research direction

Start with jobs/cloud_controller_ng/templates/nginx.conf.erb and the existing cc.client_max_body_size and cc.nginx_rate_limit_* properties to trace how BOSH properties reach the nginx http block. Add the property with the documented default and constraints, then verify the rendered configuration includes large_client_header_buffers and explains limits imposed by Puma and other network hops.

Written by the indexing model from the issue text.

Description

Feature request

Expose nginx's large_client_header_buffers as a BOSH property on the cloud_controller_ng job.

Context

CF v3 encourages guid-list filters on list endpoints (guids=, space_guids=, organization_guids=, user_guids=, ...). Clients that resolve or enrich entities in bulk legitimately build long request URIs — 200 guids is already ~7.5KB encoded.

jobs/cloud_controller_ng/templates/nginx.conf.erb does not set large_client_header_buffers, so CC's fronting nginx runs the compiled default (4 8k): request lines over ~8KB are rejected with 414 Request-URI Too Large before reaching Cloud Controller. There is no BOSH property to change this — an operator who needs wider filter URIs has to fork the job template.

Client-side impact precedent: cloudfoundry/cli#2220 (cf routes failing with 414 on /v3/apps?guids= for larger foundations; the v8 fix batches at 200 guids per request). Stratos hits the same wall (cloudfoundry/stratos#5579).

Proposal

Add a property, e.g.:

cc.nginx_large_client_header_buffers:
  description: "Value for nginx large_client_header_buffers (number and size of buffers for large request headers, including the request line). nginx default is '4 8k'."
  default: "4 8k"

rendered into the http block of nginx.conf.erb. This follows the pattern of the request-shaping knobs already exposed there (cc.client_max_body_size, cc.nginx_rate_limit_general, cc.nginx_rate_limit_zones).

Notes for the docs/description

  • The next wall is puma's query-string parser cap (10KB, PUMA_QUERY_STRING_MAX_LENGTH), so the useful range for this property without also touching puma is roughly 8k-10k.
  • The effective limit a client experiences is the minimum across every hop in front of CC (edge load balancers, proxies, gorouter, this nginx). It would help operators if the property description says this plainly — raising CC's buffer only helps if the rest of the chain also allows longer request lines.
Dominant language
HTML
Stars
24
Forks
110
Avg merge
3d 12h
Merged PRs (30d)
8

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from cloudfoundry/capi-release

All issues in cloudfoundry/capi-release

Similar issues

More DevOps issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.