/src/le/libevent/bufferevent_ssl.c:863: error: Null Dereference
pointer `bev_ssl` last assigned on line 855 could be null and is dereferenced at line 863, column 6.
861. r2 = start_writing(bev_ssl);
862.
863. if (bev_ssl->underlying) {
^
864. if (events & EV_READ)
865. BEV_RESET_GENERIC_READ_TIMEOUT(bev);
Once SSL_read() only get max 16K bytes (one TLS record).
In case of big buffer, should more SSL_read() to fill the buffer.
Using sample https-client to measure max income MBit/s via nload tool.
Note: set bufferevent_set_max_single_read() by 32K and add the chunk
callback to read out each piece of data.
The client sample do https request a data 900KB (the server don't use
Transfer-Encoding: chunked)
- With origin/master: max income is 2.26 MBit/s
The chunk callback never get a piece of data > 16K.
- With this PR: max income is 2.44 MBit/s
The chunk callback can get some piece of data 32K or more.
Previously in case when evbuffer_reserve_space() returns > 1, but
it was able to read only 1 IO vector, it will try to read the next one,
got 0 (EOF for mbedTLS or SSL_ERROR_ZERO_RETURN for OpenSSL) and will
trigger EOF, while instead, it should trigger EV_READ w/o EOF and only
after EOF.
SSL write may do partial writes in some cases. For example, document
of mbedtls_ssl_write says:
If the return value is non-negative but less than length, the function
must be called again with updated arguments: buf + ret, len - ret
(if ret is the return value) until it returns a value equal to the
last 'len' argument.
In case of partial writes, we should continue writing the same chain of
buffer, not the next chain.
This will avoid this icky error:
$ https-client -4 -url https://127.1
some request failed - no idea which one though!
error:00000005:lib(0):func(0):DH lib
And instead will report only:
$ https-client -4 -url https://127.1
some request failed - no idea which one though!
socket error = Connection refused (111)
Refs: #1115
This patch splits common part out to avoid copy-paste from the
- bufferevent_openssl.c
- bufferevent_mbedtls.c
It uses VFS/bufferevent-like approach, i.e. structure of callbacks.
