Expose nginx large_client_header_buffers as a BOSH property on cloud_controller_ng

[nabramovitz]

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.

[nabramovitz]

Withdrawing for now while we review existing capi-release/cloud_controller_ng issues and PRs for prior art on request-line limits; will reopen or file fresh with that context if it still stands.

[nabramovitz]

Reopening after reviewing capi-release and cloud_controller_ng history for prior art on request-line limits. What's there:

• HTTP 414 on executing cf service-access cloud_controller_ng#823 (2017): cf service-access hit the same 414 via a long service_guid IN ... query. Raising large_client_header_buffers was mentioned as an option in that thread, but the issue was closed as CLI work, and the CLI later shipped fixed-size guid batching (cf routes fails with 414 Request-URI Too Large if "too many" applications cli#2220). That was a client bug, and it predates v3's guid-list filter design. This request is a different proposition: an operator-facing property with the default unchanged. Client-side batching remains the right client behavior — we are doing that in Stratos regardless — but batch sizing today has to guess at a limit only the operator can see.
• capi-release#170 (2020): the closest prior attempt to make nginx config elements property-driven; it was closed for inactivity, not on the merits.
• Merged precedent for property-backed nginx directives on this exact job: cc.server_keepalive_timeout (Increase nginx keepalive_timeout to 100s #558), cc.client_max_body_size / cc.app_bits_max_body_size (Increase default max nginx upload size to 2GB #358, which also raised a default), plus the existing cc.nginx_* rate-limit and logging properties.
• No prior mention of large_client_header_buffers in this repo's code, issues, or PRs.

So: not a duplicate, not previously rejected, and #558 is a near-identical shape (one directive, one property). The request stands as filed.