Kong issue with backend routing in Kong 3.7.1 in Service resources vs 2.8.x.

[jeremyjpj0916]

Is there an existing issue for this?

• [X] I have searched the existing issues

Kong version ($ kong version)

3.7.1

Current Behavior

On Kong 2.8.x we did not observe this. In Kong 3.7.1 we do:

The service resource we have like so:

{
  "id": "76d80c70-b0eb-4a38-bf55-d5d06c5349ad",
  "write_timeout": 9000,
  "protocol": "https",
  "tls_verify": null,
  "tls_verify_depth": null,
  "read_timeout": 9000,
  "host": "myapi.company.com",
  "tags": null,
  "created_at": 1713416244,
  "updated_at": 1713416244,
  "path": "/api/test/moretest/v2.0/",
  "client_certificate": null,
  "enabled": true,
  "retries": 0,
  "name": "boss.boss.popproductv2.stage",
  "ca_certificates": null,
  "port": 443,
  "connect_timeout": 2000,
  "extras": {}
}

Route resource like:

{
  "regex_priority": 0,
  "protocols": [
    "http",
    "https"
  ],
  "request_buffering": true,
  "response_buffering": true,
  "https_redirect_status_code": 426,
  "name": null,
  "headers": null,
  "snis": null,
  "sources": null,
  "tags": null,
  "paths": [
    "/api/stage/cel/test/tester/v2"
  ],
  "created_at": 1713416354,
  "preserve_host": false,
  "updated_at": 1721296030,
  "path_handling": "v1",
  "methods": null,
  "strip_path": true,
  "service": {
    "id": "76d80c70-b0eb-4a38-bf55-d5d06c5349ad"
  },
  "hosts": null,
  "id": "5c8b6cc0-e682-49ae-b7ea-c18528965bdb",
  "destinations": null
}

Consumed url ends up gateway.company.com/api/stage/cel/test/tester/v2

Kong 2.8.x would not drop the trailing / when proxying. New Kong 3.7.1 testing it routes to the backside without the / so it tries: /api/test/moretest/v2.0 when it goes to the backend and it returns 404 now because that trailing slash is relevant to API responses. Would like fixes asap if possible to not drop / on service backend api paths.

Backend URL should be myapi.company.com/api/test/moretest/v2.0/ Kong routes to: myapi.company.com/api/test/moretest/v2.0

Expected Behavior

Kong should not drop service path values from a configured resource on proxying. If the service path ends on a / Kong should be respecting that /, certainly when using path handling v1 as the unit tests and docs say it will.

Steps To Reproduce

No response

Anything else?

No response

[jeremyjpj0916]

router_flavor = traditional_compatible we do not override this field so it stays defaulted to this in our runtimes.

[jeremyjpj0916]

Some more insights for yall after further testing since last night was a mad dash to fix whatever I could however I could:

This test essentially does not pass in real life with functionality on 3.7.1 where on 2.8.x it passes:

https://github.com/Kong/kong/blob/master/spec/fixtures/router_path_handling_tests.lua#L91

"path_handling": "v1" on route calling /route path, on 2.8.x series will respect the service resource path trailing slash like /service/ in proxy calls

"path_handling": "v1" on route calling /route, on 3.7.1 series will NOT respect the service trailing slash like /service/ in service resource path , actually sends traffic to /service in behavior and drops the trailing /.

This is breaking behavior for some APIs Kong may proxy to.

[chronolaw]

path_handling 'v1' is deprecated since Kong gateway 3.0, the only available value is 'v0', I think that we should find a warning message in the log.

[chronolaw]

See change logs of 3.0 and this PR (https://github.com/Kong/kong/pull/9290).

[jeremyjpj0916]

@chronolaw deprecated is very different from breaking behavior. An application should honor existing functionality even when deprecated.

[chronolaw]

Perhaps you could try flavor = traditional, it still supports path_handling='v1'.

[jeremyjpj0916]

That is a potential option I had considered but there is performance loss with that mode right? And traditional is going away is my understanding hence why we continued with 3.7.x default provided value.

And does Kong have a plan to migrate v1 path handlings to v0 when v1 will be moved from deprecated to deleted? Kinda odd Kong is doing reverse versioning there where v0 is preferred but v1 is the deprecated, usually +1 version iterations are the next iteration of a feat. vs considered legacy. And in the future I suppose the field should go away completely if there was only one in the future, shouldn't be configurable maybe in 4.x . I still think this is a pretty glaring issue in between the 2.x to 3.x versions for customers that use Kong. Some of the new routing behaviors of Kong don't seem to make common sense anymore for this issue and the other one I raised.