Sync docs from master to gh-pages

multi/multi__spring_cloud_config_server.html

@@ -383,5 +383,5 @@ If you do supply a secret, you should also encrypt the secret using a custom <co
 However, you might occasionally  need to change the keys (for example, in the event of a security breach).
 In that case, all the clients would need to change their source config files (for example, in git) and use a new <code class="literal">{key:&#8230;&#8203;}</code> prefix in all the ciphers.
 Note that the clients need to first check that the key alias is available in the Config Server keystore.</p><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Tip"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Tip]" src="images/tip.png"></td><th align="left">Tip</th></tr><tr><td align="left" valign="top"><p>If you want to let the Config Server handle all encryption as well as decryption, the <code class="literal">{name:value}</code> prefixes can also be added as plain text posted to the <code class="literal">/encrypt</code> endpoint, .</p></td></tr></table></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="_serving_encrypted_properties" href="#_serving_encrypted_properties"></a>2.8&nbsp;Serving Encrypted Properties</h2></div></div></div><p>Sometimes you want the clients to decrypt the configuration locally, instead of doing it in the server.
-In that case, if you provide the <code class="literal">encrypt.*</code> configuration to locate a key, you can still have <code class="literal">/encrypt</code> and <code class="literal">/decrypt</code> endpoints, but you need to explicitly switch off the decryption of outgoing properties by setting <code class="literal">spring.cloud.config.server.encrypt.enabled=false</code>.
+In that case, if you provide the <code class="literal">encrypt.*</code> configuration to locate a key, you can still have <code class="literal">/encrypt</code> and <code class="literal">/decrypt</code> endpoints, but you need to explicitly switch off the decryption of outgoing properties by placing <code class="literal">spring.cloud.config.server.encrypt.enabled=false</code> in <code class="literal">bootstrap.[yml|properties]</code>.
 If you do not care about the endpoints, it should work if you do not configure either the key or the enabled flag.</p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="multi__quick_start.html">Prev</a>&nbsp;</td><td width="20%" align="center">&nbsp;</td><td width="40%" align="right">&nbsp;<a accesskey="n" href="multi__serving_alternative_formats.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">1.&nbsp;Quick Start&nbsp;</td><td width="20%" align="center"><a accesskey="h" href="multi_spring-cloud-config.html">Home</a></td><td width="40%" align="right" valign="top">&nbsp;3.&nbsp;Serving Alternative Formats</td></tr></table></div></body></html>

single/spring-cloud-config.html

@@ -467,7 +467,7 @@ If you do supply a secret, you should also encrypt the secret using a custom <co
 However, you might occasionally  need to change the keys (for example, in the event of a security breach).
 In that case, all the clients would need to change their source config files (for example, in git) and use a new <code class="literal">{key:&#8230;&#8203;}</code> prefix in all the ciphers.
 Note that the clients need to first check that the key alias is available in the Config Server keystore.</p><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary="Tip"><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Tip]" src="images/tip.png"></td><th align="left">Tip</th></tr><tr><td align="left" valign="top"><p>If you want to let the Config Server handle all encryption as well as decryption, the <code class="literal">{name:value}</code> prefixes can also be added as plain text posted to the <code class="literal">/encrypt</code> endpoint, .</p></td></tr></table></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="_serving_encrypted_properties" href="#_serving_encrypted_properties"></a>2.8&nbsp;Serving Encrypted Properties</h2></div></div></div><p>Sometimes you want the clients to decrypt the configuration locally, instead of doing it in the server.
-In that case, if you provide the <code class="literal">encrypt.*</code> configuration to locate a key, you can still have <code class="literal">/encrypt</code> and <code class="literal">/decrypt</code> endpoints, but you need to explicitly switch off the decryption of outgoing properties by setting <code class="literal">spring.cloud.config.server.encrypt.enabled=false</code>.
+In that case, if you provide the <code class="literal">encrypt.*</code> configuration to locate a key, you can still have <code class="literal">/encrypt</code> and <code class="literal">/decrypt</code> endpoints, but you need to explicitly switch off the decryption of outgoing properties by placing <code class="literal">spring.cloud.config.server.encrypt.enabled=false</code> in <code class="literal">bootstrap.[yml|properties]</code>.
 If you do not care about the endpoints, it should work if you do not configure either the key or the enabled flag.</p></div></div><div class="chapter"><div class="titlepage"><div><div><h1 class="title"><a name="_serving_alternative_formats" href="#_serving_alternative_formats"></a>3.&nbsp;Serving Alternative Formats</h1></div></div></div><p>The default JSON format from the environment endpoints is perfect for consumption by Spring applications, because it maps directly onto the <code class="literal">Environment</code> abstraction.
 If you prefer, you can consume the same data as YAML or Java properties by adding a suffix (".yml", ".yaml" or ".properties") to the resource path.
 This can be useful for consumption by applications that do not care about the structure of the JSON endpoints or the extra metadata they provide (for example, an application that is not using Spring might benefit from the simplicity of this approach).</p><p>The YAML and properties representations have an additional flag (provided as a boolean query parameter called <code class="literal">resolvePlaceholders</code>) to signal that placeholders in the source documents (in the standard Spring <code class="literal">${&#8230;&#8203;}</code> form) should be resolved in the output before rendering, where possible.

spring-cloud-config.xml

@@ -943,7 +943,7 @@ Note that the clients need to first check that the key alias is available in the
 <section xml:id="_serving_encrypted_properties">
 <title>Serving Encrypted Properties</title>
 <simpara>Sometimes you want the clients to decrypt the configuration locally, instead of doing it in the server.
-In that case, if you provide the <literal>encrypt.*</literal> configuration to locate a key, you can still have <literal>/encrypt</literal> and <literal>/decrypt</literal> endpoints, but you need to explicitly switch off the decryption of outgoing properties by setting <literal>spring.cloud.config.server.encrypt.enabled=false</literal>.
+In that case, if you provide the <literal>encrypt.*</literal> configuration to locate a key, you can still have <literal>/encrypt</literal> and <literal>/decrypt</literal> endpoints, but you need to explicitly switch off the decryption of outgoing properties by placing <literal>spring.cloud.config.server.encrypt.enabled=false</literal> in <literal>bootstrap.[yml|properties]</literal>.
 If you do not care about the endpoints, it should work if you do not configure either the key or the enabled flag.</simpara>
 </section>
 </chapter>