I filed https://issues.apache.org/jira/browse/SOLR-18055 & https://issues.apache.org/jira/browse/SOLR-18056
Eric, I think SOLR-18053 is only loosely related but I linked it anyway. On Sun, Jan 4, 2026 at 10:13 AM Eric Pugh <[email protected]> wrote: > Quite agree! > > There are so many settings that are defined in the bin/solr scripts that > probably could be simplified with the new EnvUtils capability. > > I opened https://issues.apache.org/jira/browse/SOLR-18053 that would be > to track just the work you are highlighting! > > Eric > > On 2026/01/03 23:46:08 Jan Høydahl wrote: > > Agree with all you say. This gives me a de-ja-vu to an old JIRA, still > open: https://issues.apache.org/jira/browse/SOLR-9640 where I intended to > remove urlScheme cluster property, but it never materialized... > > > > Jan > > > > > 4. jan. 2026 kl. 00:17 skrev David Smiley <[email protected]>: > > > > > > I was looking into how Solr supports SSL / "https". The user side is > > > mostly SOLR_SSL_ENABLED, which maps to *no* system property, by the > way. > > > EnvToSyspropMappings.properites has a final section of env vars that > don't > > > map to any system properties, and this is included. bin/solr is > currently > > > the only consumer of this env var, which it uses to set a Jetty https > > > module and a variety of other settings (albeit not "urlScheme"?). > Within > > > Solr at runtime, it seems our primary consideration is a "urlScheme" > > > setting (to either "http" or "https"), both in some SolrCloud related > > > places and HttpShardHandlerFactory. I was hoping SearchHandler might > > > indirectly pass on the URL scheme of its incoming request as a default > for > > > outgoing requests, but it doesn't work that way. > > > > > > It's not clear to me why SolrCloud has cluster level settings on the > matter > > > ("urlScheme" cluster property) when there are (adequate?) node level > > > settings, just discussed. Maybe it's required for CloudSolrClient when > > > using ZkClientClusterStateProvider if somehow it can't trust the URLs > > > present in ZK. > > > > > > CloudSolrClient (which can't generally consume solr node settings like > > > SOLR_SSL_ENABLED) seems to use the urlScheme from Solr's cluster props > as > > > held in ZK but IMO ideally we'd ask the clusterStateProvider with a new > > > method specifically for this (e.g. getUrlScheme), and > > > HttpClusterStateProvider could simply return the the prefix of the > initial > > > quorum nodes provided on instantiation. > > > > > > I propose that SOLR_SSL_ENABLED be mapped to a system property (by > simply > > > removing a line in EnvToSyspropMappings.properites), and that > > > HttpShardHandlerFactory default the urlScheme based on that. > Similarly in > > > testing, I think org.apache.solr.SolrTestCaseJ4#setupTestCases should > *not* > > > set a "urlScheme" system property, but instead "solr.ssl.enabled" true. > > > Probably remove the urlScheme line in all test solr.xml files. > > > Thoughts/concerns? > > > > > > ~ David Smiley > > > Apache Lucene/Solr Search Developer > > > http://www.linkedin.com/in/davidwsmiley > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
