[TT-10626] extended_paths path handling is inconsistent

[jakub-bochenski]

Branch/Environment/Version

• Branch/Version: v5.1
• Environment: On-prem

Describe the bug

For different elements in the extended_paths structure the path handling is inconsistent.
Furthermore the details are not documented (based on https://tyk.io/docs/transform-traffic/url-rewriting/ and https://tyk.io/docs/getting-started/key-concepts/versioning/)

• url_rewrites.path matches: version and path but not query parameters v1/fooBar
• url_rewrites.match_pattern matches: listen path and version and path and query parameters myApi/v1/fooBar?baz
• ignore/white_list/black_list.path matches: listen path and version and path but not query parameters myApi/v1/fooBar

So you have all the possible different combinations to increase confusion.

I think including version in the path is counter-productive and only produces bloat. Extended paths are configured under a particular version so there is no need to include it in the matching logic.

The same goes for listen path.

Also the documentation states

The wildcard {id} is transformed into a wide regex ((.*)) to ensure that everything possible is captured.

Whereas in fact I've found out that it's replaced with [^/]* -- see https://github.com/TykTechnologies/tyk/blob/master/gateway/api_definition.go#L721

[andyo-tyk]

Hi @jakub-bochenski,

Thanks for flagging this - it looks like we've got a real muddle of inconsistency there. It will be difficult to align everything without making breaking changes, but this is now on my radar. We should definitely be able to improve things in our Tyk OAS functionality, though the Tyk Classic will be tricky or impossible to resolve.

In terms of the documentation, I've raised a ticket internally to improve this so that - even if the behaviour is inconsistent between different fields - we make it as clear as possible what rules are applied where.

Thanks again for your support - I'll leave this open until we've managed to improve the docs.

[hbirkdale]

I can add to this. We tested with two endpoints:
/ping
/core/ping

We put in the white_list /ping, and it is allowed, but core/ping also now is allowed. I would think this needs to be strict or clearly documented. I put /ping in the white list, and its the only endpoint in the white list, then suddenly allowing /core/ping makes no sense. I get the fact that $ at the end will stop /ping/core - but what about at the beginning of the url?