From: Cyril Bonté Date: Tue, 9 Oct 2012 20:45:34 +0000 (+0200) Subject: DOC: ssl: surround keywords with quotes X-Git-Tag: v1.5-dev13~178 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=9c1eb1e8bed3f6efe92b3d07637f12fe82c24584;p=thirdparty%2Fhaproxy.git DOC: ssl: surround keywords with quotes In order to make external tools easily detect keywords in the documentation, let's surround them by quotes as it is done for other keywords. --- diff --git a/doc/configuration.txt b/doc/configuration.txt index 96b479680d..b44cb5f878 100644 --- a/doc/configuration.txt +++ b/doc/configuration.txt @@ -8313,30 +8313,30 @@ ssl_sni layer which deciphered it and found a Server Name Indication TLS extension sent by the client, matching the specified string. In HTTPS, the SNI field (when present) is equal to the requested host name. This match is different - from req_ssl_sni above in that it applies to the connection being deciphered - by haproxy and not to SSL contents being blindly forwarded. See also - ssl_sni_end and ssl_sni_req below. This requires that the SSL library is - build with support for TLS extensions enabled (check haproxy -vv). + from "req_ssl_sni" above in that it applies to the connection being + deciphered by haproxy and not to SSL contents being blindly forwarded. + See also "ssl_sni_end" and "ssl_sni_req" below. This requires that the SSL + library is build with support for TLS extensions enabled (check haproxy -vv). ssl_sni_end Returns true when the incoming connection was made over an SSL/TLS transport layer which deciphered it and found a Server Name Indication TLS extension sent by the client, ending like the specified string. In HTTPS, the SNI field (when present) is equal to the requested host name. This match is different - from req_ssl_sni above in that it applies to the connection being deciphered - by haproxy and not to SSL contents being blindly forwarded. This requires - that the SSL library is build with support for TLS extensions enabled (check - haproxy -vv). + from "req_ssl_sni" above in that it applies to the connection being + deciphered by haproxy and not to SSL contents being blindly forwarded. This + requires that the SSL library is build with support for TLS extensions + enabled (check haproxy -vv). ssl_sni_req Returns true when the incoming connection was made over an SSL/TLS transport layer which deciphered it and found a Server Name Indication TLS extension sent by the client, matching the specified regex. In HTTPS, the SNI field (when present) is equal to the requested host name. This match is different - from req_ssl_sni above in that it applies to the connection being deciphered - by haproxy and not to SSL contents being blindly forwarded. This requires - that the SSL library is build with support for TLS extensions enabled (check - haproxy -vv). + from "req_ssl_sni" above in that it applies to the connection being + deciphered by haproxy and not to SSL contents being blindly forwarded. This + requires that the SSL library is build with support for TLS extensions + enabled (check haproxy -vv). ssl_verify_caerr Returns true when the incoming connection was made over an SSL/TLS transport