From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Date: Thu, 21 Jan 2010 08:44:38 +0000 (+0100)
Subject: Added documentation of rehandshake usage in gnutls if full-duplex capability is required.
X-Git-Tag: gnutls_2_9_10~158
X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=925e23875bb3b3c1ff8b287cc213982a5ff75e13;p=thirdparty%2Fgnutls.git

Added documentation of rehandshake usage in gnutls if full-duplex capability is required.
---

diff --git a/lib/gnutls_handshake.c b/lib/gnutls_handshake.c
index b4e81649bb..618b20c506 100644
--- a/lib/gnutls_handshake.c
+++ b/lib/gnutls_handshake.c
@@ -1257,7 +1257,6 @@ _gnutls_recv_handshake_header (gnutls_session_t session,
 
       if (ret < 0)
 	{
-	  gnutls_assert ();
 	  return ret;
 	}
 
@@ -2520,6 +2519,13 @@ _gnutls_recv_hello (gnutls_session_t session, opaque * data, int datalen)
   * gnutls_handshake() function in order to negotiate the new
   * parameters.
   *
+  * Since TLS is full duplex some application data might have been
+  * sent during peer's processing of this message. In that case
+  * one should call gnutls_record_recv() until GNUTLS_E_REHANDSHAKE
+  * is returned to clear any pending data. Care must be taken if
+  * rehandshake is mandatory to terminate if it does not start after
+  * some threshold.
+  *
   * If the client does not wish to renegotiate parameters he will
   * should with an alert message, thus the return code will be
   * %GNUTLS_E_WARNING_ALERT_RECEIVED and the alert will be