The method org.apache.solr.client.solrj.impl.HttpSolrClientBuilderBase#withTheseParamNamesInTheUrl is only used by UpdateShardHandler so that "distrib.from" and "update.distrib" (used by DistributedUpdateProcessor) are guaranteed to be in the URL. It appears Dat added this during the http2 branch merge in 2018 but I don't see why since posting update info will require that all params go in the URL anyway (payload is javabin not form data). You might try commenting this out and seeing what breaks. If nothing, let's deprecate/remove.
On Fri, Jan 10, 2025 at 12:23 PM Jason Gerlowski <gerlowsk...@gmail.com> wrote: > Hey all, > > SolrJ's SolrClient implementations have an interesting bit of logic > around how they handle SolrParams. > > In short: params are attached tothe request differently based on a > quite detailed series of checks. "GET" requests attach params to the > URL as traditional "query parameters". "POST and "PUT" requests also > use URL query parameters, unless the request-body happens to be > unused. In which case, SolrClient's encode the SolrParams as "form > parameters" in the request body. Except for any parameters where > URL-query-param treatment has been explicitly allowlisted by the > `withTheseParamNamesInTheUrl()` SolrClient builder method. And so > on... > > This all feels a little complex to me, but perhaps that's just my own > ignorance of the discussion behind it. Does anyone remember the > rationale behind this chunk of the SolrJ code? Are we doing this to > avoid URI-length issues perhaps? Are there other reasons? > > Just hoping to understand things a bit better; thanks in advance if > anyone happens to know! > > Best, > > Jason > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > >
