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.
---
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 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);
--
2.26.2
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
