Update pre9
This commit is contained in:
+32
-21
@@ -51,40 +51,47 @@ call. If B<num> is higher than the number of bytes buffered then the read
|
||||
functions will return with the bytes buffered. If no more bytes are in the
|
||||
buffer, the read functions will trigger the processing of the next record.
|
||||
Only when the record has been received and processed completely will the read
|
||||
functions return reporting success. At most the contents of the record will
|
||||
functions return reporting success. At most the contents of one record will
|
||||
be returned. As the size of an SSL/TLS record may exceed the maximum packet size
|
||||
of the underlying transport (e.g. TCP), it may be necessary to read several
|
||||
packets from the transport layer before the record is complete and the read call
|
||||
can succeed.
|
||||
|
||||
If B<SSL_MODE_AUTO_RETRY> has been switched off and a non-application data
|
||||
record has been processed, the read function can return and set the error to
|
||||
B<SSL_ERROR_WANT_READ>.
|
||||
In this case there might still be unprocessed data available in the B<BIO>.
|
||||
If read ahead was set using L<SSL_CTX_set_read_ahead(3)>, there might also still
|
||||
be unprocessed data available in the B<SSL>.
|
||||
This behaviour can be controlled using the L<SSL_CTX_set_mode(3)> call.
|
||||
|
||||
If the underlying BIO is B<blocking>, a read function will only return once the
|
||||
read operation has been finished or an error occurred, except when a
|
||||
renegotiation takes place, in which case a SSL_ERROR_WANT_READ may occur. This
|
||||
behaviour can be controlled with the SSL_MODE_AUTO_RETRY flag of the
|
||||
L<SSL_CTX_set_mode(3)> call.
|
||||
non-application data record has been processed and B<SSL_MODE_AUTO_RETRY> is
|
||||
not set.
|
||||
Note that if B<SSL_MODE_AUTO_RETRY> is set and only non-application data is
|
||||
available the call will hang.
|
||||
|
||||
If the underlying BIO is B<non-blocking>, a read function 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 L<SSL_get_error(3)> with the
|
||||
operation.
|
||||
In this case a call to L<SSL_get_error(3)> with the
|
||||
return value of the read function will yield B<SSL_ERROR_WANT_READ> or
|
||||
B<SSL_ERROR_WANT_WRITE>. As at any time a re-negotiation is possible, a
|
||||
a read function can also cause write operations! The calling process then must
|
||||
repeat the call after taking appropriate action to satisfy the needs of the read
|
||||
function. The action depends on the underlying BIO. When using a non-blocking
|
||||
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.
|
||||
B<SSL_ERROR_WANT_WRITE>.
|
||||
As at any time it's possible that non-application data needs to be sent,
|
||||
a read function can also cause write operations.
|
||||
The calling process then must repeat the call after taking appropriate action
|
||||
to satisfy the needs of the read function.
|
||||
The action depends on the underlying BIO.
|
||||
When using a non-blocking 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.
|
||||
|
||||
L<SSL_pending(3)> can be used to find out whether there
|
||||
are buffered bytes available for immediate retrieval. In this case
|
||||
the read function can be called without blocking or actually receiving
|
||||
new data from the underlying socket.
|
||||
|
||||
=head1 WARNING
|
||||
|
||||
When a read function operation has to be repeated because L<SSL_get_error(3)>
|
||||
returned B<SSL_ERROR_WANT_READ> or B<SSL_ERROR_WANT_WRITE>, it must be repeated
|
||||
with the same arguments.
|
||||
are buffered bytes available for immediate retrieval.
|
||||
In this case the read function can be called without blocking or actually
|
||||
receiving new data from the underlying socket.
|
||||
|
||||
=head1 RETURN VALUES
|
||||
|
||||
@@ -119,6 +126,10 @@ You should instead call SSL_get_error() to find out if it's retryable.
|
||||
|
||||
=back
|
||||
|
||||
=head1 HISTORY
|
||||
|
||||
SSL_read_ex() and SSL_peek_ex() were added in OpenSSL 1.1.1.
|
||||
|
||||
=head1 SEE ALSO
|
||||
|
||||
L<SSL_get_error(3)>, L<SSL_write_ex(3)>,
|
||||
|
||||
Reference in New Issue
Block a user