envoyproxy / envoy

Cloud-native high-performance edge/middle/service proxy
https://www.envoyproxy.io
Apache License 2.0
24.26k stars 4.69k forks source link

Support OData endpoint in UriTemplateMatchConfig #34507

Open DieBauer opened 4 weeks ago

DieBauer commented 4 weeks ago

Title: OData style endpoints cannot be configured in UriTemplateMatchConfig

Description:

Describe the desired behavior, what scenario it enables and how it would be used.

I have a route with a path parameter, /api/MyFunction('{id}') this is following the OData specification[0].

If I add this to Envoy's path_match_policy

"path_match_policy": {
                        "name": "envoy.path.match.uri_template.uri_template_matcher",
                        "typed_config": {
                            "@type": "type.googleapis.com/envoy.extensions.path.match.uri_template.v3.UriTemplateMatchConfig",
                            "path_template": "/api/MyFunction('{id}')"
                        }
                    }

it fails with

Error adding/updating listener(s) incoming: path_match_policy.path_template /api/MyFunction('{id}') is invalid

The desired behavior is that I can match on these endpoints in Envoy.

[optional Relevant Links:] 0 https://docs.oasis-open.org/odata/odata/v4.0/os/part2-url-conventions/odata-v4.0-os-part2-url-conventions.html#_Toc372793769

adisuissa commented 4 weeks ago

It would be helpful if Envoy also printed the reason for the path template to be invalid at: https://github.com/envoyproxy/envoy/blob/9f362305cb693bcf95ca419e0b0fe871f5220612/source/extensions/path/match/uri_template/config.h#L26 - I'll submit a PR for this.

cc @alyssawilk @yanjunxiang-google as code-owners for supporting OData style endpoints.

DieBauer commented 3 weeks ago

I was looking for some example that does implement the full UriTemplate grammar according to spec (RFC6570) and found https://github.com/apiaryio/drafter/blob/master/packages/apib-parser/src/grammar/Uritemplate.h under MIT license which is implemented fully in PEGTL.

I think the main issue currently is that Envoy expects the path param to be always defined between slashes / and {, } are (rightfully so) not valid literals. I don't see how this can be extended without resorting to some parser..

yanjunxiang-google commented 3 weeks ago

It would be helpful if Envoy also printed the reason for the path template to be invalid at:

https://github.com/envoyproxy/envoy/blob/9f362305cb693bcf95ca419e0b0fe871f5220612/source/extensions/path/match/uri_template/config.h#L26

  • I'll submit a PR for this. cc @alyssawilk @yanjunxiang-google as code-owners for supporting OData style endpoints.

Sure, please print the error reason.

yanjunxiang-google commented 3 weeks ago

I was looking for some example that does implement the full UriTemplate grammar according to spec (RFC6570) and found https://github.com/apiaryio/drafter/blob/master/packages/apib-parser/src/grammar/Uritemplate.h under MIT license which is implemented fully in PEGTL.

I think the main issue currently is that Envoy expects the path param to be always defined between slashes / and {, } are (rightfully so) not valid literals. I don't see how this can be extended without resorting to some parser..

There are different parser libraries for H1/H2/H3. For example, H1/Balsa: https://github.com/envoyproxy/envoy/blob/a6792927ff71015069326490af5306ad56d769c9/source/common/http/http1/balsa_parser.h#L20. Do we need a parser here or just write customized code to support RFC?