aboutsummaryrefslogtreecommitdiffstats
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
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)
-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);