On Wed, May 13, 2020 at 12:35 AM Jan Ekström <jee...@gmail.com> wrote:
>
> 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

 LGTM.

- Hendrik
_______________________________________________
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".

Reply via email to