Skip to content

URL Path Matching - Listen Path - Regex #6693

Open
@CamokA1071

Description

Branch/Environment/Version
TYK Open Source Api Gateway Version 5.3.7 LTS

Describe the bug
I upgraded my TYK open source api gateway from version 5.0.0 to 5.3.7 LTS.
However, my previously working apis with similar listen_path started redirecting to wrong targets.
Requests that I send API2 are constantly going to API1.

Reproduction steps
Steps to reproduce the behavior:
every time a request is made to these 2 apis

Expected behavior
My only wish is to be able to use it by making an exact match in listen_path like the old version, but it doesn’t work.

Configuration (tyk config file):
{
"listen_port": 443,
"control_api_port": 8443,
"secret": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"template_path": "/opt/tyk-gateway/templates",
"use_db_app_configs": false,
"app_path": "/opt/tyk-gateway/apps",
"middleware_path": "/opt/tyk-gateway/middleware",
"storage": {
"type": "redis",

"addrs": [
"xxxxxxxxxxx:26379",
"xxxxxxxxxxx:26379",
"xxxxxxxxxxx:26379"
],

"username": "",
"password": xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
"master_name": xxxxxxxxxxxxxxxxxxxxxxxxx,

"database": 0,


"optimisation_max_idle": 20000,
"optimisation_max_active": 40000

},
"enable_analytics": true,
"analytics_config": {
"enable_detailed_recording": false
},
"health_check": {
"enable_health_checks": false,
"health_check_value_timeouts": 60
},
"dns_cache": {
"enabled": false,
"ttl": 3600
},
"allow_master_keys": false,
"policies": {
"policy_source": "file",
"policy_record_name": "policies/policies.json"
},
"hash_keys": true,
"enable_hashed_keys_listing": true,
"suppress_redis_signal_reload": false,
"close_connections": false,
"enable_non_transactional_rate_limiter": true,
"enable_sentinel_rate_limiter": false,
"local_session_cache": {
"disable_cached_session_state": false
},
"uptime_tests": {
"disable": false,
"config": {
"enable_uptime_analytics": false,
"failure_trigger_sample_size": 2,
"time_wait": 10,
"checker_pool_size": 50
}
},
"http_server_options": {
"enable_path_prefix_matching": true,
"enable_path_suffix_matching": true,
"enable_http2": true,
"min_version": 771,
"enable_websockets": true,
"ssl_insecure_skip_verify": true,
"use_ssl": true,
"server_name": "",
"certificates": [
{
"domain_name": "*.abc.com.tr",
"cert_file": "xxxxxxxxxxxxxxxxxxxxxxx
"key_file": "xxxxxxxxxxxxxxxxxxxxxxx
}
]
},
"proxy_ssl_insecure_skip_verify": true,
"bundle_insecure_skip_verify": true,
"hostname": "",
"enable_custom_domains": true,
"proxy_enable_http2": true,
"enable_jsvm": true,
"oauth_redirect_uri_separator": ";",
"coprocess_options": {
"enable_coprocess": false,
"coprocess_grpc_server": "",
"python_path_prefix": "/opt/tyk-gateway"
},
"pid_file_location": "./tyk-gateway.pid",
"allow_insecure_configs": true,
"public_key_path": "",
"close_idle_connections": false,
"allow_remote_config": false,
"enable_bundle_downloader": true,
"bundle_base_url": "",
"global_session_lifetime": 100,
"force_global_session_lifetime": false,
"max_idle_connections_per_host": 5000,

"log_level": "info"
}

Additional context
I upgraded my TYK open source api gateway from version 5.0.0 to 5.3.7 LTS.
However, my previously working apis with similar listen_path started redirecting to wrong targets.
Requests that I send API2 are constantly going to API1.

API1 listen_path :

"proxy": {
"listen_path": "/abc-def/web/",
"target_url": "https://www.abc.com",
"strip_listen_path": false
},
API2 listen_path :

"proxy": {
"listen_path": "/abc-def/public/xyz/",
"target_url": "https://www.abc.com",
"strip_listen_path": false
},
I tried using both control characters (^ and $) in listen_path but could not get an exact match. ( ^/json$ )

I added the following variables to the tyk.conf file but it did not work:
“http_server_options”: {
“enable_path_prefix_matching”: true,
“enable_path_suffix_matching”: true,
“enable_strict_routes”: true,

My only wish is to be able to use it by making an exact match in listen_path like the old version, but it doesn’t work.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions