I have 2 vague recollections of concepts/reasons for why some of the SSL stuff (may) works the way it does.
(not saying either of these are concretely true, or should be blockers for making changes to the way things work -- just saying you may want to consider them and investigate further if they make sense) 1) migration from http -> https w/rolling restart + no downtime I think some of the design choices around enabling SSL were made with the idea that if you wanted to switch from http to https it should be possible to do that w/o any cluster downtime -- so i think the idea is that you could first enable *both* http and https at the jetty config level, then do a rolling restart of every node, then update the urlScheme cluster prop, then remove http from the jetty config and do another rolling restart (pretty sure this is why the cluster level prop exists instead of nodes assuming their locally configured SSL settings indicate what scheme to use when making remote requests) 2) using https externally, and http internally I think at one point it might have been possible to "advertise" that external clients should use https urls, but internally the cluster could use http? (this may be a memory hallucination -- but I think it's why requests / SearchHandler don't assume the incoming scheme is the same as the schema used for distributed requests) : 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]
