client is claiming when they run custom extractions and downloading the output file with S3 direct header they are getting below error:
We got TLS errors frequently today (maybe since last week). We had to retry several times to get the files downloaded, and this caused delays.
Take file DAILY-1MIN-EURO2-20230825.csv.gz for example. The file id is 0x0899d721a3e90bfd. Error logs (including RequestId) like below:
<?xml version="1.0" encoding="UTF-8"?>
<Error><Code>InvalidTlsVersion</Code><Message>Amazon S3 will stop supporting TLS 1.0 and TLS 1.1 connections. Please update your client to use TLS version 1.2 or above. To learn more and to update your client, see https://go.aws/3AUlVSb. For further assistance, contact AWS support.</Message><RequestId>JKXGNP0M3VQGQX13</RequestId><HostId>XBQEirTiGjLByJz42qN4hHq35v6bL4xAjgFAZRzav7W/GzTIN8j0xZS4Jj9HaEy2pTHM/YhFeZU=</HostId></Error> :
at DataScope.Select.Api.Core.HttpOData.Http.HttpClientExceptionDecorator+<ParseResponseError>d__1b.MoveNext () [0x0057a] in <f747139363544b3990dfff486c66c322>:0
Could you please confirm the TLS version that MLP sent to Refinitiv side?
If MLP sent TLS1.2 or TLS1.3, could you please check further why it became TLS1.1 on Refinitiv side?
If MLP sent TLS1.1, could you please advise how to specify TLS version in DataScope.Select.RestApi.Client (version 17.2, with .NET Framework 4.8)?
Btw, according to our logs, the TLS error was not consistent, it’s usually gone after retried several times. So I suspect the issue is on some of your load-balance servers.