On 02/05/2024 11:52, Rahul Shukla wrote:
Thank you for the quick reply, Matt !!
Is my understanding correct thatif the buffer is empty and SSL_peek() is
invoked while trying to process more records, only application data gets
placed into that buffer?
Technically, the internal buffer is reused to temporarily hold the
non-application data. But that is invisible to callers of
SSL_peek()/SSL_read(). While the internal buffer is holding
non-application data any calls to SSL_peek()/SSL_read() will return no
data (if a non-blocking socket is in use), or will block until app data
is available (if a blocking socket is in use).
Matt
--Rahul
On Thu, May 2, 2024 at 12:33 PM Matt Caswell <matt@xxxxxxxxxxx
<mailto:matt@xxxxxxxxxxx>> wrote:
On 02/05/2024 06:19, Rahul Shukla wrote:
> Hi All,
> As per the OpenSSL doc :
> /
> /
> /"SSL_peek_ex() and SSL_peek() are identical to SSL_read_ex() and
> SSL_read() respectively except no bytes are actually removed from
the
> underlying BIO during the read, so that a subsequent call to
> SSL_read_ex() or SSL_read() will yield at least the same bytes."/
>
> *I have a quick question here, Does SSL_peek() remove the session
ticket
> (Non application data) from the underlying BIO or will it remain
there
> just like application data until unless SSL_read() is called to
read the
> session ticket. *
It depends.
OpenSSL has an internal buffer of application data that has already
been
processed and is available for immediate read. If that buffer has data
in it then a call to SSL_peek() (or in fact SSL_read()) will return
that
data and will not attempt to process any further incoming records.
If the buffer is empty then it will attempt to process further records
in order to put more data into that buffer. In doing that if it
encounters any non-application data records (such as a session ticket)
then it will process those records in the same way as SSL_read() would
have done.
Matt
