What is the user's expected outcome if http.search.max_content_length is more than http.max_content_length and a search request that is larger than the latter but less than the former is sent? Right now we will fail and to me this violates the principle of least astonishment. It seems this setting would only help when http.search.max_content_length is less than http.max_content_length. While this is the case by default (1 MB versus 100 MB) I still wonder if this setting is the right path forward because of the potential for confusion? Maybe this setting is targeting large term queries? If so, should we focus on those only?

Maybe this setting is targeting large term queries? If so, should we focus on those only?

I tend to like the fact that such a setting would catch more abuse cases than if we solely focused on the terms query, for instance large percolated documents, match queries on very long text, too complex geo-shapes, long lists of stored fields (not bounded by the number of mapped fields since we simply ignore unmapped fields), very large include lists on terms aggregations, etc. which are all bad practice if they end up making the request that large.

Would you be ok with fixing the potential confusion you mentioned with documentation?

@jpountz do you plan on coming back to this?

We chatted about this in FixitFriday and were uneasy with how broad but not necessarily specific this soft limit is. E.g. large search requests are often bad, but you can definitely have a large request which is perfectly reasonable (long field names + many simple aggregations + long agg names, etc).

Jason's point about confusing overlap with request body size is a concern too.

We decided it would be better to try and tackle bad queries through more specific mechanisms (breakers, better validation of queries after parsing, etc).

Decided to close for now.