TYK v4.3.4 giving SSL errors on a streaming API

Support
,
1

Hi All

We are facing an issue in TYK v4.3.4 while using an streaming API where the API executes for 4-5 minutes. We already have timeouts configured at 10 minutes.

But on hitting the API it is giving below error in client response:
Error in the HTTP2 framing layer

We also tried to lower down the HTTP2 to HTTP1.1 (using enable_http2: false) version, but then error changed to below:
curl: (56) OpenSSL SSL_read: error:1408F119:SSL routines:ssl3_get_record:decryption failed or bad record mac, errno 0

Can anyone please check if we are missing any configuration in v4.3.4 as in v2.5.1 same API works normally.

This is blocking us to upgrade, so need urgent support.

@Olu @James @patric @zaid

Thanks

2

Are there any changes or difference in the gateway config and API definition? Is it exactly the same? Can you share the config and definition files?

I have only seen the first error once Error HTTP/2 stream 0 was not closed cleanly: - #4 by zaid and it doesn’t appear a resolution was reached.

You mentioned the issue was on hitting the API. This would mean its not occurring at random or after a number of requests?

What is the flow of the request? I assume hitting the upstream works as expected.

Also how are the certs generated? Maybe this link could help point in the right direction

Part of the error message “bad record mac” indicates that the SSL/TLS connection is failing due to a decryption error or a bad record message authentication code (MAC).

3

Hi @Olu

Thanks for quick response.

Are there any changes or difference in the gateway config and API definition? Is it exactly the same?

Yes, all the configurations and definitions are same earlier. you can refer our conf here DRL Rate-limiting failing edge case 1-2 calls in TYK v4.3.4 - #4 by Mohit_Kumar

This would mean its not occurring at random or after a number of requests?
What is the flow of the request? I assume hitting the upstream works as expected.

This error was coming when we were trying to download data above 80-90 mb in size. till 70-80 mb API is working fine. With upstream URL, all APIs were success with data up to 500 mb.

Also how are the certs generated?

Currently we have self signed certificated generated & configured.

Today we have made below changes in our tyk.conf, that resolved the issue for now:
“flush_interval”: 1,
“read_timeout”: 2000
“write_timeout”: 2000
“proxy_default_timeout”: 1200

only proxy_default_timeout was changed from 600 to 1200, others confs added newly.
are these configurations looks OK & recommended for streaming API use cases (where 300-500 mb data is being transferred).

Also on removing enable_http2 conf also we see HTTP1.1 request, is that OK.

4

This is great news! Glad to hear it is working as expected

Are you asking if your configurations are recommended settings?

Network latency, speed and other external factors could contribute to the rate of data transfer.

Yes, I believe that is the intention of the flag

5

yes, just wanted to be sure so that there should not be any consequence of these changes on other APIs, deployment etc.