Snowpark Scala transmet les options de proxy à sa connexion JDBC

Snowpark Scala se connecte avec le pilote JDBC Snowflake. Son constructeur de session accepte les propriétés de configuration JDBC, donc les réglages de proxy peuvent voyager avec la carte de connexion existante :

val proxyOptions = Map(
  "useProxy" -> "true",
  "proxyHost" -> "proxy.example",
  "proxyPort" -> "8080"
)

val session = com.snowflake.snowpark.Session.builder
  .configs(connectionOptions ++ proxyOptions)
  .create

connectionOptions contient le compte, l'authentification et les autres réglages déjà utilisés par l'application. Ce sont des entrées de map de chaînes Scala ; le nom d'hôte du proxy n'inclut ni schéma d'URL ni port. Pour une route par proxy public autorisée et sans authentification de proxy, choisissez l'hôte et le port dans la liste de proxys HTTP tout en conservant les réglages du compte Snowflake.

Le pilote JDBC Snowflake documente aussi proxyUser et proxyPassword pour un compte intermédiaire. Fournissez-les via la source d'identifiants existante de l'application lorsque c'est nécessaire.

Le nonProxyHosts de JDBC utilise des motifs séparés par des barres verticales avec prise en charge des jokers. Dans une valeur de map, le séparateur est un | littéral ; l'encodage d'URL n'intervient qu'à la construction d'une URL JDBC. Ne le remplacez pas par la syntaxe NO_PROXY séparée par des virgules d'un autre client.

Gardez cette configuration propre à Snowpark Scala. Snowpark Python et le connecteur Snowflake pour Spark exposent des interfaces de connexion et des noms d'options différents.

Snowflake exige que le certificat de service traverse le proxy sans remplacement. Une route HTTP CONNECT et l'inspection TLS sont deux dispositifs différents ; un proxy qui réémet le certificat Snowflake ne satisfait pas cette exigence.