I really appreciate the historical context, Hoss! On Mon, Jan 5, 2026 at 4:29 PM Chris Hostetter <[email protected]> wrote:
> > 1) migration from http -> https w/rolling restart + no downtime > I think this could continue to work by manually specifying the urlScheme on all nodes, and doing a round of rolling restarts, maybe 2 rounds if you want to ultimately remove what eventually becomes a redundant default. 2) using https externally, and http internally > I suspect nowadays that is more likely to be achieved by a load balancer / proxy with SSL. Anyway, this should continue to work as I don't propose removing the ability to explicitly configure the urlScheme. What I don't think needs to survive is the urlScheme SolrCloud cluster property. Its complexity should be removed eventually, once the defaulting I suggested is in place. ~ David > > > > : Date: Sat, 3 Jan 2026 18:17:32 -0500 > : From: David Smiley <[email protected]> > : Reply-To: [email protected] > : To: [email protected] > : Subject: SSL / urlScheme, -- analysis, questions, proposals > : > : 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 > : > > -Hoss > http://www.lucidworks.com/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
