Complex filter query gets escaped

[Aculeo]

What are you generating using Kiota, clients or plugins?

API Client/SDK

In what context or format are you using Kiota?

Nuget tool

Client library/SDK language

Csharp

Describe the bug

I am attempting send a request that has the following query parameter:

<url>?filter=[_and][0][location][_eq]=123

This is the normal filter syntax for Directus, headless CMS / backend system. Docs: https://docs.directus.io/reference/query.html#filter

Most of the parameters are simple enough to set:

 var member = await apiClient.Items.Members.GetAsMembersGetResponseAsync(r =>
{
    r.QueryParameters.Sort = ["sort", "-member_number"];
    r.QueryParameters.Limit = 1;
    r.QueryParameters.Fields = ["member_number"];
    r.QueryParameters.Filter = [$"[_and][0][location][_eq]={locationId}"];

But the filter parameter gets escaped when I check the actual URL getting called:

<url>/items/members?fields=member_number&filter=%5B_and%5D%5B0%5D%5Blocation%5D%5B_eq%5D%3D1&limit=1&sort=sort,-member_number

Not sure if it's a bug or I am doing this wrong, but I would appreciate any help to get this working.

Expected behavior

Complex filter query should not be escaped: <url>?filter=[_and][0][location][_eq]=123

How to reproduce

Somewhat difficult to provide, the OpenAPI spec is dynamically generated based upon the setup of the Directus instance. I can attempt to provide a smaller sample if necessary.

I set up Kiota like this (token was just taken from browser):

curl -X GET "<directus-url>/server/specs/oas" -H "Authorization: Bearer eyJhbGc..." > openapi.yaml

kiota generate --openapi openapi.yaml --namespace-name MyNamespace --output Services/Api --language csharp --clean-output

Open API description file

No response

Kiota Version

1.19.1

Latest Kiota version known to work for scenario above?(Not required)

No response

Known Workarounds

No response

Configuration

No response

Debug output

No response

Other information

No response

[baywet]

Hi @Aculeo
Thank you for using kiota and for reaching out.

This is caused by the fact that clients use URI templates - RFC 6570 to project URLs and their parameter values. And the RFC dictates the encoding of such characters

The template (found in the request builder class), probably looks something like this: {+baseurl}/items/members{?sort*,field*,filter*}

The filter value gets encoded while the template is expanded.

Although it's not a hard requirement from RFC9110, servers usually decode percent encoded characters in query parameters values. Maybe this is hidden behind a configuration option? (if you run the service/server)

Another option is to decode the query parameters values in a middleware handler before the request is sent on the network.
This example only cares about query parameter names (the $ sign in odata query parameters) but could easily be adapted to your scenario.

Let us know if you have any additional comments or questions.