Loading...

Blocked:
False
Ready:
False
Discussed with Team:
No
Test Coverage:

+
Workaround Description:

Hide

Disable TLS Termination in APIcast
OR
Disable keepalive by configuring HTTP_KEEPALIVE_TIMEOUT=0 in APIcast

Show
Disable TLS Termination in APIcast OR Disable keepalive by configuring HTTP_KEEPALIVE_TIMEOUT=0 in APIcast
Steps to Reproduce:
Hide

Download and extract reproducing_env.tar.gz

Start APIcast with ./start_apicast_keepalive_routing_policy.sh

Execute the script that fires multiple requests from the same session to the two paths configured, with: python fire_requests.py

This will produce logs similar to those found in logs/logs_script_routing_policy.log where the problem is visible
Show
Download and extract reproducing_env.tar.gz Start APIcast with ./start_apicast_keepalive_routing_policy.sh Execute the script that fires multiple requests from the same session to the two paths configured, with: python fire_requests.py This will produce logs similar to those found in logs/logs_script_routing_policy.log where the problem is visible

APIcast routes requests to the wrong backend.

This happens when backends use the same host for the same service(product). So if a product has two backends

A request e.g. 'POST https://{backend-host}/c ' can be routed incorrectly to backend 1 as 'POST https://{backend-host}//a/b/c' instead of being routed to backend 2. So the request fails.

Notes:

The apicast log statement "Rule matched <url>" shows the wrong the backend being selected.
keepalive connection is used . HTTPS is used from both client to APIcast and from APICast to backend .

This can be reproduced when:

APIcast is configured to terminate TLS (either with environment variables, or with the tls termination policy)
A client is configured to reuse the open TCP connection
Multiple requests are sent from the client targeting different Backends configured each on its own path, on the same product

links to

KCS

mentioned on

APIcast sometimes selects wrong backend