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
Today warning headers returned on client responses can be unbounded in size without a user knob to control this. Such warning headers can accumulate rapidly on, for example, bulk indexing requests using deprecated fields (e.g., string for keyword and text) across many fields. This can cause problems when there is a proxy between clients which limits the buffer size for proxy responses. This issue proposes adding a cluster level byte size setting that allows users to limit the size of warning headers sent on client HTTP responses. The default should be unbounded.
It's possible that the proxy rejects the headers because of their number rather than/as well as their total size. It might be useful to limit the number of headers too.
Yes, please! We've just his this issue on Kibana/ES/ECE deployment, where ECE proxy chokes up on a bunch of warning coming from ES to Kibana and that basically made our Kibana permanently broken until we dropped the index that was generating warnings...
…responses
Add a dynamic persistent cluster level setting "http.max_warning_header_count"
to control the maximum number of warning headers in client HTTP responses.
Defaults to unbounded.
Add a dynamic persistent cluster level setting "http.max_warning_header_size"
to control the maximum total size of warning headers in client HTTP responses.
Defaults to unbounded.
Closeselastic#28301
Add a dynamic persistent cluster level setting
"http.max_warning_header_count" to control the maximum number of
warning headers in client HTTP responses.
Defaults to unbounded.
Add a dynamic persistent cluster level setting
"http.max_warning_header_size" to control the maximum total size of
warning headers in client HTTP responses.
Defaults to unbounded.
Once any of these limits is exceeded this will be logged in the main
ES log, and any more warning headers for this response will be
ignored.
Closeselastic#28301
Today warning headers returned on client responses can be unbounded in size without a user knob to control this. Such warning headers can accumulate rapidly on, for example, bulk indexing requests using deprecated fields (e.g.,
string
forkeyword
andtext
) across many fields. This can cause problems when there is a proxy between clients which limits the buffer size for proxy responses. This issue proposes adding a cluster level byte size setting that allows users to limit the size of warning headers sent on client HTTP responses. The default should be unbounded.Relates #17804
The text was updated successfully, but these errors were encountered: