[
https://issues.apache.org/jira/browse/SOLR-17221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17913585#comment-17913585
]
ASF subversion and git services commented on SOLR-17221:
--------------------------------------------------------
Commit 82083ea13ad2b2114d4311439be2f90ed868fac1 in solr's branch
refs/heads/main from Yue Yu
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=82083ea13ad ]
SOLR-17221: Fix Http2SolrClient merging case sensitive solr params (#3028)
If multiple query param keys are sent that only vary by case, they were wrongly
merged when doing distributed search (sharded collections). This could likely
occur for fielded parameters such as f.CASE_SENSITIVE_FIELD.facet.limit=50
Also: compose the request content directly using SolrParams.toQueryString().
This will avoid to use Jetty Fields as an intermediary mapping
---------
Co-authored-by: David Smiley <dsmi...@apache.org>
> Http2SolrClient merges case sensitive solr params
> -------------------------------------------------
>
> Key: SOLR-17221
> URL: https://issues.apache.org/jira/browse/SOLR-17221
> Project: Solr
> Issue Type: Bug
> Components: SolrJ
> Affects Versions: 9.5
> Reporter: Yue Yu
> Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> In solr9.5.0/solrj9.5.0, the multi-shard requests are sent through
> Http2SolrClient, and this function composes the actual Jetty Request object:
> {code:java}
> private Request fillContentStream(
> Request req,
> Collection<ContentStream> streams,
> ModifiableSolrParams wparams,
> boolean isMultipart)
> throws IOException {
> if (isMultipart) {
> // multipart/form-data
> try (MultiPartRequestContent content = new MultiPartRequestContent()) {
> Iterator<String> iter = wparams.getParameterNamesIterator();
> while (iter.hasNext()) {
> String key = iter.next();
> String[] vals = wparams.getParams(key);
> if (vals != null) {
> for (String val : vals) {
> content.addFieldPart(key, new StringRequestContent(val), null);
> }
> }
> }
> if (streams != null) {
> for (ContentStream contentStream : streams) {
> String contentType = contentStream.getContentType();
> if (contentType == null) {
> contentType = "multipart/form-data"; // default
> }
> String name = contentStream.getName();
> if (name == null) {
> name = "";
> }
> HttpFields.Mutable fields = HttpFields.build(1);
> fields.add(HttpHeader.CONTENT_TYPE, contentType);
> content.addFilePart(
> name,
> contentStream.getName(),
> new InputStreamRequestContent(contentStream.getStream()),
> fields);
> }
> }
> req.body(content);
> }
> } else {
> // application/x-www-form-urlencoded
> Fields fields = new Fields();
> Iterator<String> iter = wparams.getParameterNamesIterator();
> while (iter.hasNext()) {
> String key = iter.next();
> String[] vals = wparams.getParams(key);
> if (vals != null) {
> for (String val : vals) {
> fields.add(key, val);
> }
> }
> }
> req.body(new FormRequestContent(fields, FALLBACK_CHARSET));
> }
> return req;
> } {code}
> The problem is the use of this class *Fields fields = new Fields();* where
> caseSensitive=false by default, this leads to case sensitive solr params
> being merged together. For example f.case_sensitive_field.facet.limit=5 &
> f.CASE_SENSITIVE_FIELD.facet.limit=99
> Not sure if this is intentional for some reason?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
