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.
This commit is contained in:
Cyril Bont 2012-10-09 22:45:34 +02:00 committed by Willy Tarreau
parent 0d44fc6472
commit 9c1eb1e8be

View File

@ -8313,30 +8313,30 @@ ssl_sni <string>
layer which deciphered it and found a Server Name Indication TLS extension 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 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 (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 from "req_ssl_sni" above in that it applies to the connection being
by haproxy and not to SSL contents being blindly forwarded. See also deciphered by haproxy and not to SSL contents being blindly forwarded.
ssl_sni_end and ssl_sni_req below. This requires that the SSL library is See also "ssl_sni_end" and "ssl_sni_req" below. This requires that the SSL
build with support for TLS extensions enabled (check haproxy -vv). library is build with support for TLS extensions enabled (check haproxy -vv).
ssl_sni_end <string> ssl_sni_end <string>
Returns true when the incoming connection was made over an SSL/TLS transport 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 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 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 (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 from "req_ssl_sni" above in that it applies to the connection being
by haproxy and not to SSL contents being blindly forwarded. This requires deciphered by haproxy and not to SSL contents being blindly forwarded. This
that the SSL library is build with support for TLS extensions enabled (check requires that the SSL library is build with support for TLS extensions
haproxy -vv). enabled (check haproxy -vv).
ssl_sni_req <regex> ssl_sni_req <regex>
Returns true when the incoming connection was made over an SSL/TLS transport 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 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 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 (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 from "req_ssl_sni" above in that it applies to the connection being
by haproxy and not to SSL contents being blindly forwarded. This requires deciphered by haproxy and not to SSL contents being blindly forwarded. This
that the SSL library is build with support for TLS extensions enabled (check requires that the SSL library is build with support for TLS extensions
haproxy -vv). enabled (check haproxy -vv).
ssl_verify_caerr <errorID> ssl_verify_caerr <errorID>
Returns true when the incoming connection was made over an SSL/TLS transport Returns true when the incoming connection was made over an SSL/TLS transport