Route via HTTP(S) assertion is using wrong port if https URL is defined without port

Products

• CA API Gateway

Issue/Introduction

Routing assertion is using wrong port if https URL is defined without port
We have an issue with the routing assertion, if the default https port is used.
For example:
Routing assertion is defined:
https://<GATEWAY_HOST>/X0062_001_AwsSendEmail

In some cases the error from the routing looks like:
Problem routing to https://<GATEWAY_HOST>/X0062_001_AwsSendEmail/.

Error msg: 
Unable to obtain HTTP response from https://<GATEWAY_HOST>/X0062_001_AwsSendEmail/: Connect to <GATEWAY_HOST>:7711 timed out
-> Why is the routing using port 7711 instead of no port or default https port?

Having reviewed a tcpdump where stream 9 is using port 7711.
Time is UTC, means effective time is 16:30:28.342553
2021-07-01 14:30:28.342553 10.xx.xx.xx 172.xx.xx.xx TCP 66 34736 → 7711 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 WS=512 00:50:56:9d:89:c2 00:22:bd:f8:19:f0

All calls before and after are using the correct default https port 443.
I found out, that immediately before this call, another service has used port 7711 for the routing.
-> https://<GATEWAY_HOST>:7711

2021-07-01T16:30:28.317+0200 INFO    16097188 com.l7tech.traffic: 2021-07-01T14:30:28.301Z\thttps://<GATEWAY_HOST>:7711\tGenesysUrsApi_1\tGET\tundefined\tAPP-676\t0\ttrue\t2\tCN=esg-xx.xx.xx.xxx.xxx, OU=xx:xx, O=xx-xx\tundefined\trest\t200\txx.xxx.xx.xx\tundefined\tundefined\tundefined\tundefined\t8791cecd-0f5e-44f4-9f24-17b0f8e4e90e\tfb1ece0d-1802-44e0-bc98-c1e48e8127af\tundefined\t/rest/genesys-urs/v1/*\t12

A possible workaround which is working is to add the default port 443 to the routing URL:
https://<GATEWAY_HOST>:443/X0062_001_AwsSendEmail
instead
https://<GATEWAY_HOST>/X0062_001_AwsSendEmail

It looks like if no port is defined in the http routing assertion, the gateway picks in some seldom cases a wrong port which is used immediately before from another service for the routing.

Furthermore,  the customer has a default listener port (8443) which is serving all REST API's and SOAP services.
Their issue is related to the routing assertion.
I also recognized, the issue only appears if we are using the "main" tab for the URL definition. If we are using the "Multiple URL's" part in the "Connection" tab, the issue does not appear.

Environment

Release : 10.0

Component : API GATEWAY

Cause

Discussed with the development ..

Our routing assertion creates http client for every request, but reuses the connection manager.  Hence, it is the most likely the issue from the third party
library we use i.e., Apache HTTP client.

>> Debug might not help in this case because, we see this problem in the burst of requests scenario.

>> specifying the port explicitly solves the problem; hence, we advise the users to explicitly use the port until Apache HTTP Client library is updated which would be in the future release; however, I don't have a precious date for it.

Resolution

specifying the port explicitly solves the problem; hence, we advise the users to explicitly use the port until Apache HTTP Client library is updated which would be in the future release; however, we don't have any precious
dates for it.