Open DieBauer opened 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.
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..
It would be helpful if Envoy also printed the reason for the path template to be invalid at:
- 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.
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?
Title: OData style endpoints cannot be configured in UriTemplateMatchConfig
Description:
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
it fails with
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