Kong issue with backend routing in Kong 3.7.1 in Service resources vs 2.8.x. other service pathing issues

[jeremyjpj0916]

Is there an existing issue for this?

• I have searched the existing issues

Kong version ($ kong version)

3.7.1

Current Behavior

Both with route using: "path_handling": "v1", which is deprecated but should still behave with same behavior. And traditional_compatible default running 3.7.x

2.8.x routing behaviors:

Route in Kong: /api/clm/apiresource/v2
Service Host +port + path: myapi.com:443/my/api/v2

Consumer calls: gateway.com/api/clm/apiresource/v2.0
Kong calls API behind it with: myapi.com:443/my/api/v2.0

So Kong gets extra .0 on end of proxy url and appends it to the backend host like people would expect gateways to.

3.7.x routing behaviors:

Route in Kong: /api/clm/apiresource/v2
Service Host +port + path: myapi.com:443/my/api/v2

Consumer calls: gateway.com/api/clm/apiresource/v2.0
Kong calls API behind it with: myapi.com:443/my/api/v2/.0

So Kong gets extra .0 on end of proxy url and appends /.0 it to the backend host which breaks apis that do v{major}.{minor} proxy URL routing and is not expected.

Slightly similar to my other trailing / issue but slightly different issue here in breaking change too.

Expected Behavior

Kong should always smart append what the customer passes on proxy url appended to backend URLs and not add extra characters. 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.

Steps To Reproduce

No response

Anything else?

No response

[chronolaw]

The default router flavor is traditional_compatible, which only supports path_handling = v0. If you want the complete compatibility with 2.x, you could set the router flavor to traditional, which supports both v0 and v1.

[jeremyjpj0916]

@chronolaw Where does Kong's documentation or files state "traditional_compatible mode only supports path_handling = v0" ? And the runtime makes no mention of this either.

Kong should be working to make traditional_compatible mode be traditional compatible in all scenarios of Kong configs.

[chronolaw]

This is the document: https://docs.konghq.com/gateway/api/admin-oss/latest/#/Routes/list-route

[jeremyjpj0916]

Gotcha, yeah if I hadn't reviewed that admin api notes section I would not see this:

"Note: Path handling algorithms v1 was deprecated in Kong 3.0. From Kong 3.0, when router_flavor is set to expressions, route.path_handling will be unconfigurable and the path handling behavior will be "v0"; when router_flavor is set to traditional_compatible, the path handling behavior will be "v0" regardless of the value of route.path_handling. Only router_flavor = traditional will support path_handling "v1" behavior."

---

So in Kong defaults mode anything v1 path handling gets a breaking change when running Kong's default traditional_compatible is a important thing for all Kong users to see. Taking that stuff aside even with what Kong considers its best routing algo being v0 going forward(and the only behavior Kong now allows outside of the going away traditional mode) I still don't see how the two cases make any logical sense from an api gateway:

Case 1: How does a customer appending .0 to a proxy thats just a plain string "/my/proxy/path/v1" mean Kong should append a "/.0" to the backend service path with a random trailing / in the service path? From a common sense perspective in what world does that behavior seem reasonable and make sense ootb? I am not seeing the rational for that behavior at all.

Case 2: How does anything in the proxy route resource pathing of a non-regex plain path route like "/my/proxy/path/v1" make sense that when calling a backend host like https://my.api.com/my/service/path/v1.0/ in the service configs with trailing / on the backend make sense for Kong to drop the trailing / off the existing service path. Why should proxy path be changing the behavior of where Kong proxy routes to as the route was originally just a resource designed to dictate which proxy config to fall on. It just doesn't make sense to me why Kong would take the liberty of dropping off values from the configured service path regardless of whats in the router config.

How did these cases pass engineering QA in thinking through common use cases of API proxying? What is Kong's offered solution in these two cases that makes sense vs fixing edge cases that the route+service resources don't make common sense behavior any longer and now obfuscate behavior from expected config(ex: if I configure a backend service with a trailing / I naturally expect Kong to route to what I configured there vs having to study other resources and learn extra ways the route resource now impacts what Kong will do on the backside)?

[chobits]

hi @jeremyjpj0916 @chronolaw do you have some other things to update for this issue?