diff options
author | Jan Ekström <jeebjp@gmail.com> | 2020-05-13 00:27:58 +0300 |
---|---|---|
committer | Jan Ekström <jeebjp@gmail.com> | 2020-09-04 19:04:06 +0300 |
commit | 93d1993181abd67ec9f72dda2a390a1a4bb58c48 (patch) | |
tree | df0c7df5d273ce1cdacba910d5adbf298d819814 /libavformat/tls_schannel.c | |
parent | d359b750afcca74524a1d686d2413c41b21d8486 (diff) | |
download | ffmpeg-93d1993181abd67ec9f72dda2a390a1a4bb58c48.tar.gz |
avformat/tls_schannel: always decrypt all received data
The dec_buf seems to be properly managed between read calls,
and we have no logic to decrypt before attempting socket I/O.
Thus - until now - such data would not be decrypted in case of
connections such as HTTP keep-alive, as the recv call would
always get executed first, block until rw_timeout, and then get
retried by retry_transfer_wrapper.
Thus - if data is received - decrypt all of it right away. This way
it is available for the following requests in case they can be
satisfied with it.
(cherry picked from commit 39977fff20048f1798a95c593d6034a0e73ebbe5)
Diffstat (limited to 'libavformat/tls_schannel.c')
-rw-r--r-- | libavformat/tls_schannel.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/libavformat/tls_schannel.c b/libavformat/tls_schannel.c index 4f0badcb8d..7a8842e7fe 100644 --- a/libavformat/tls_schannel.c +++ b/libavformat/tls_schannel.c @@ -424,7 +424,7 @@ static int tls_read(URLContext *h, uint8_t *buf, int len) c->enc_buf_offset += ret; } - while (c->enc_buf_offset > 0 && sspi_ret == SEC_E_OK && c->dec_buf_offset < len) { + while (c->enc_buf_offset > 0 && sspi_ret == SEC_E_OK) { /* input buffer */ init_sec_buffer(&inbuf[0], SECBUFFER_DATA, c->enc_buf, c->enc_buf_offset); |