Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
SSL_WRITE(3ossl)		    OpenSSL		      SSL_WRITE(3ossl)

NAME
       SSL_write_ex2, SSL_write_ex, SSL_write, SSL_sendfile,
       SSL_WRITE_FLAG_CONCLUDE - write bytes to	a TLS/SSL connection

SYNOPSIS
	#include <openssl/ssl.h>

	#define	SSL_WRITE_FLAG_CONCLUDE

	ossl_ssize_t SSL_sendfile(SSL *s, int fd, off_t	offset,	size_t size, int flags);
	int SSL_write_ex2(SSL *s, const	void *buf, size_t num,
			  uint64_t flags,
			  size_t *written);
	int SSL_write_ex(SSL *s, const void *buf, size_t num, size_t *written);
	int SSL_write(SSL *ssl,	const void *buf, int num);

DESCRIPTION
       SSL_write_ex() and SSL_write() write num	bytes from the buffer buf into
       the specified ssl connection. On	success	SSL_write_ex() will store the
       number of bytes written in *written.

       SSL_write_ex2() functions similarly to SSL_write_ex() but can also
       accept optional flags which modify its behaviour. Calling
       SSL_write_ex2() with a flags argument of	0 is exactly equivalent	to
       calling SSL_write_ex().

       SSL_sendfile() writes size bytes	from offset offset in the file
       descriptor fd to	the specified SSL connection s.	This function provides
       efficient zero-copy semantics. SSL_sendfile() is	available only when
       Kernel TLS is enabled, which can	be checked by calling
       BIO_get_ktls_send().  It	is provided here to allow users	to maintain
       the same	interface.  The	meaning	of flags is platform dependent.
       Currently, under	Linux it is ignored.

       The flags argument to SSL_write_ex2() can accept	zero or	more of	the
       following flags.	Note that which	flags are supported will depend	on the
       kind of SSL object and underlying protocol being	used:

       SSL_WRITE_FLAG_CONCLUDE
	   This	 flag  is  only	 supported on QUIC stream SSL objects (or QUIC
	   connection SSL objects with a default stream	attached).

	   If this flag	is set,	and the	call to	SSL_write_ex2()	succeeds,  and
	   all	of  the	 data  passed  to  the	call  is written (meaning that
	   "*written ==	 num"),	 the  relevant	QUIC  stream's	send  part  is
	   concluded automatically as though SSL_stream_conclude(3) was	called
	   (causing transmission of a FIN for the stream).

	   While  using	 this  flag  is	 semantically  equivalent  to  calling
	   SSL_stream_conclude(3) after	a successful call  to  this  function,
	   using  this	flag  enables greater efficiency than making these two
	   API calls separately, as it enables the written stream data and the
	   FIN flag indicating the end of the stream to	be scheduled  as  part
	   of the same QUIC STREAM frame and QUIC packet.

	   Setting  this  flag	does  not  cause  a  stream's  send part to be
	   concluded if	not all	of the data passed to the call was consumed.

       A call to SSL_write_ex2() fails if  a  flag  is	passed	which  is  not
       supported  or understood	by the given SSL object. An application	should
       determine   if	a   flag    is	  supported    (for    example,	   for
       SSL_WRITE_FLAG_CONCLUDE,	 that  a QUIC stream SSL object	is being used)
       before attempting to use	it.

NOTES
       In the paragraphs below a "write	function" is defined as	one of	either
       SSL_write_ex(), or SSL_write().

       If necessary, a write function will negotiate a TLS/SSL session,	if not
       already explicitly performed by SSL_connect(3) or SSL_accept(3).	If the
       peer  requests  a  re-negotiation,  it  will be performed transparently
       during the  write  function  operation.	The  behaviour	of  the	 write
       functions depends on the	underlying BIO.

       For  the	 transparent  negotiation  to  succeed,	the ssl	must have been
       initialized to client or	server mode. This is  being  done  by  calling
       SSL_set_connect_state(3)	 or  SSL_set_accept_state()  before  the first
       call to a write function.

       If the underlying BIO  is  blocking,  the  write	 functions  will  only
       return,	once  the  write  operation  has  been	finished  or  an error
       occurred.

       If the underlying BIO is	nonblocking  the  write	 functions  will  also
       return  when  the  underlying  BIO  could  not satisfy the needs	of the
       function	 to  continue  the  operation.	In  this  case	 a   call   to
       SSL_get_error(3)	with the return	value of the write function will yield
       SSL_ERROR_WANT_READ  or	SSL_ERROR_WANT_WRITE.  As  at  any  time a re-
       negotiation is possible,	a call to a write function can also cause read
       operations! The calling process then must repeat	the call after	taking
       appropriate  action  to	satisfy	 the  needs of the write function. The
       action depends on the underlying	BIO. When using	a nonblocking  socket,
       nothing	is  to	be  done,  but	select()  can be used to check for the
       required	condition. When	using a	buffering BIO, like a BIO  pair,  data
       must  be	 written into or retrieved out of the BIO before being able to
       continue.

       The write functions will	only return with  success  when	 the  complete
       contents	 of buf	of length num has been written.	This default behaviour
       can  be	changed	 with  the  SSL_MODE_ENABLE_PARTIAL_WRITE  option   of
       SSL_CTX_set_mode(3).  When  this	 flag  is set the write	functions will
       also return with	success	when a partial	write  has  been  successfully
       completed.  In  this  case  the	write function operation is considered
       completed. The bytes are	sent and a new write call with	a  new	buffer
       (with  the already sent bytes removed) must be started. A partial write
       is performed with the size of a message block, which is 16kB.

       When used with a	QUIC SSL object,  calling  an  I/O  function  such  as
       SSL_write()  allows  internal network event processing to be performed.
       It is important that this processing  is	 performed  regularly.	If  an
       application  is	not  using thread assisted mode, an application	should
       ensure that an I/O function such	as SSL_write() is called regularly, or
       alternatively ensure that SSL_handle_events() is	called regularly.  See
       openssl-quic(7) and SSL_handle_events(3)	for more information.

WARNINGS
       When  a write function call has to be repeated because SSL_get_error(3)
       returned	 SSL_ERROR_WANT_READ  or  SSL_ERROR_WANT_WRITE,	 it  must   be
       repeated	 with the same arguments.  The data that was passed might have
       been partially processed.  When SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER was
       set using SSL_CTX_set_mode(3) the pointer can  be  different,  but  the
       data and	length should still be the same.

       You  should  not	 call SSL_write() with num=0, it will return an	error.
       SSL_write_ex() can be called with num=0,	but will not send  application
       data to the peer.

RETURN VALUES
       SSL_write_ex()  and  SSL_write_ex2()  return  1	for  success  or 0 for
       failure.	 Success means that all	requested application data bytes  have
       been written to the SSL connection or, if SSL_MODE_ENABLE_PARTIAL_WRITE
       is in use, at least 1 application data byte has been written to the SSL
       connection.  Failure  means  that not all the requested bytes have been
       written yet (if SSL_MODE_ENABLE_PARTIAL_WRITE is	 not  in  use)	or  no
       bytes	could	 be    written	  to	the    SSL    connection   (if
       SSL_MODE_ENABLE_PARTIAL_WRITE is	in use).  Failures  can	 be  retryable
       (e.g.  the  network  write  buffer  has	temporarily filled up) or non-
       retryable (e.g. a fatal network error). In the event of a failure  call
       SSL_get_error(3)	 to  find  out	the reason which indicates whether the
       call is retryable or not.

       For SSL_write() the following return values can occur:

       > 0 The write operation was successful, the return value	is the	number
	   of bytes actually written to	the TLS/SSL connection.

       <= 0
	   The	 write	operation  was	not  successful,  because  either  the
	   connection was closed, an error occurred or action must be taken by
	   the calling process.	 Call SSL_get_error() with  the	 return	 value
	   ret to find out the reason.

	   Old documentation indicated a difference between 0 and -1, and that
	   -1  was retryable.  You should instead call SSL_get_error() to find
	   out if it's retryable.

       For SSL_sendfile(), the following return	values can occur:

       >= 0
	   The write operation was successful, the return value	is the	number
	   of  bytes of	the file written to the	TLS/SSL	connection. The	return
	   value can be	less than size for a partial write.

       < 0 The	write  operation  was  not  successful,	 because  either   the
	   connection was closed, an error occurred or action must be taken by
	   the calling process.	 Call SSL_get_error() with the return value to
	   find	out the	reason.

SEE ALSO
       SSL_get_error(3),   SSL_read_ex(3),   SSL_read(3)  SSL_CTX_set_mode(3),
       SSL_CTX_new(3), SSL_connect(3), SSL_accept(3) SSL_set_connect_state(3),
       BIO_ctrl(3), ssl(7), bio(7)

HISTORY
       The  SSL_write_ex()  function  was  added  in   OpenSSL	 1.1.1.	   The
       SSL_sendfile()  function	was added in OpenSSL 3.0.  The SSL_write_ex2()
       function	was added in OpenSSL 3.3.

COPYRIGHT
       Copyright 2000-2024 The OpenSSL Project Authors.	All Rights Reserved.

       Licensed	under the Apache License 2.0 (the "License").  You may not use
       this file except	in compliance with the License.	 You can obtain	a copy
       in   the	  file	 LICENSE   in	the   source   distribution   or    at
       <https://www.openssl.org/source/license.html>.

3.5.4				  2025-09-30		      SSL_WRITE(3ossl)

Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=SSL_write&sektion=3&manpath=FreeBSD+15.0-RELEASE+and+Ports>

home | help