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
