[FFmpeg-cvslog] avformat/tls_schannel: always decrypt all received data

[Jan Ekström]

ffmpeg | branch: release/3.2 | Jan Ekström <jeebjp at gmail.com> | Wed May 13 00:27:58 2020 +0300| [14002368999cda9ee64872889f939ed22e5fba48] | committer: Jan Ekström

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)

> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=14002368999cda9ee64872889f939ed22e5fba48
---

 libavformat/tls_schannel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/tls_schannel.c b/libavformat/tls_schannel.c
index a8907eb3bb..b0ce6b88fa 100644
--- a/libavformat/tls_schannel.c
+++ b/libavformat/tls_schannel.c
@@ -422,7 +422,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);