1 files changed, 42 insertions, 0 deletions
diff --git a/doc/functions/gnutls_rehandshake b/doc/functions/gnutls_rehandshake
new file mode 100644
index 0000000..7498d6e
--- /dev/null
+++ b/doc/functions/gnutls_rehandshake
@@ -0,0 +1,42 @@
+
+
+
+
+@deftypefun {int} {gnutls_rehandshake} (gnutls_session_t @var{session})
+@var{session}: is a @code{gnutls_session_t}  type.
+
+This function can only be called in server side, and
+instructs a TLS 1.2 or earlier client to renegotiate
+parameters (perform a handshake), by sending a
+hello request message.
+
+If this function succeeds, the calling application
+should call @code{gnutls_record_recv()}  until @code{GNUTLS_E_REHANDSHAKE} 
+is returned to clear any pending data. If the @code{GNUTLS_E_REHANDSHAKE} 
+error code is not seen, then the handshake request was
+not followed by the peer (the TLS protocol does not require
+the client to do, and such compliance should be handled
+by the application protocol).
+
+Once the @code{GNUTLS_E_REHANDSHAKE}  error code is seen, the
+calling application should proceed to calling
+@code{gnutls_handshake()}  to negotiate the new
+parameters.
+
+If the client does not wish to renegotiate parameters he
+may reply with an alert message, and in that case the return code seen
+by subsequent @code{gnutls_record_recv()}  will be
+@code{GNUTLS_E_WARNING_ALERT_RECEIVED}  with the specific alert being
+@code{GNUTLS_A_NO_RENEGOTIATION} .  A client may also choose to ignore
+this request.
+
+Under TLS 1.3 this function is equivalent to @code{gnutls_session_key_update()} 
+with the @code{GNUTLS_KU_PEER}  flag. In that case subsequent calls to
+@code{gnutls_record_recv()}  will not return @code{GNUTLS_E_REHANDSHAKE} , and
+calls to @code{gnutls_handshake()}  in server side are a no-op.
+
+This function always fails with @code{GNUTLS_E_INVALID_REQUEST}  when
+called in client side.
+
+@strong{Returns:} @code{GNUTLS_E_SUCCESS}  on success, otherwise a negative error code.
+@end deftypefun