Pinging @elastic/es-search (Team:Search)

@pryadko I had a few questions to make sure we have all the context.

• First, where are you receiving the error "414 Request-URI Too Long"? Is it from a proxy layer, client, or Elasticsearch itself?
• Also, what is your use case for providing all these fields? Is it possible to use field name patterns (like *) instead of specifying the fields individually?

@jtibshirani
This error comes from the Elasticsearch server.
* isn't an option because you may receive fields that you don't request
use case - the user wants to know mappings for some specific fields.

This is somehow similar to #61141 , but for fields and very specific to the field_caps API. I do worry that there are possibly many other places where a similar change should be made if we go down this route. I marked it for discussion with the team.

@pryadko sorry for the slow reply. I discussed with the team, and confirmed that Elasticsearch should not be throwing "414 "Request-URI Too Long". This must be coming from some other place, like a web server. Maybe it's possible to change the server configuration to allow larger requests?

We also recognized how the change we made could cause inconvenience. In other places like search you can pass parameters like fields in the body.

@jtibshirani thank you for your answer.
Allowing larger requests on ES server doesn't really solve this issue because nobody guarantee that tomorrow we won't have "414 "Request-URI Too Long" for some combination of request, also I don't think it is good idea to configure ES server in such a way to allow actually any request with such long URI.

Do you have a plan to fix this? or it still continues discussion?
It will be good to allow user to choose which way to provide fields via URI or payload.

We don't have immediate plans to change this. The motivation for removing the ability to specify fields in the body was that we wanted only one way to specify the parameter. When there are multiple ways, it's unclear which one takes precedence (or if they're somehow merged together). This is part of our API design guidelines so we'd prefer not to undo that change.

We are still discussing the topic internally though, I'll post an update if anything changes.

@jtibshirani thanks,
I see it as a general issue for all APIs

https://www.elastic.co/guide/en/elasticsearch/reference/current/search-search.html#search-search-api-query-params

Several options for this API can be specified using a query parameter or a request body parameter. If both parameters are specified, only the query parameter is used.

I'm looking forward to your decision.

@elastic/es-clients do you have a suggestion for how to move forward? We want to avoid making a breaking change, like removing the ability to pass fields through a URI parameter. I see two options:

• Re-add support for fields in the request body. This violates our convention of "one single way to pass a parameter", but follows the convention of "passing variable-length request components in the request body".
• Just close without making changes to minimize disruption.

We discussed offline and decided to re-add support for fields in the request body. We do not want to deprecate passing fields in the URI, as this could place a burden on users upgrading. This seemed like the best compromise given the situation.

I don't think I have time to tackle this soon, but I am marking it as "help wanted".

@jtibshirani thank you, I will try to help with this.

Hi! I would love to help, you think I can give it a try?