aboutsummaryrefslogtreecommitdiffstats
path: root/libavformat/tls_schannel.c
diff options
context:
space:
mode:
authorJan Ekström <jeebjp@gmail.com>2020-05-13 00:27:58 +0300
committerJan Ekström <jeebjp@gmail.com>2020-09-04 19:04:06 +0300
commit93d1993181abd67ec9f72dda2a390a1a4bb58c48 (patch)
treedf0c7df5d273ce1cdacba910d5adbf298d819814 /libavformat/tls_schannel.c
parentd359b750afcca74524a1d686d2413c41b21d8486 (diff)
downloadffmpeg-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.c2
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);