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