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 20:46:29 +0300 |
| commit | 895f67bbed4360ffbf507b0cfb2c98b3e17a7266 (patch) | |
| tree | 77c2d8362ab45b102486c43fedefb84d761ab79e | |
| parent | 30891d0932c884afb86589a8b1121df9c1fd052f (diff) | |
| download | ffmpeg-895f67bbed4360ffbf507b0cfb2c98b3e17a7266.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.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/libavformat/tls_schannel.c b/libavformat/tls_schannel.c index 1c65c25441..7718681495 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); |