Fix failure on REST requests with $filter and $orderby parameters

[RubenCerna2079]

Why make this change?

• Fix issue [Bug]: Regression Unable to extract $filter parameter from query string. #3662

This issue is caused by a regression in PR #3080

What is this change?

This change fixes a bug that caused using $filter or $orderby in REST. This is done by replacing the URL-encoded special character into its counterpart as a '$' sign, which is what is expected for this sign to be inside the URL.

How was this tested?

• Integration Tests
• Unit Tests
  Added end to end test to ensure that REST requests that use $filter and $orderby succeed.

Sample Request(s)

http://localhost:5000/api/Book?$orderby=id desc
http://localhost:5000/api/Book?$filter=publisher_id 1234

[Copilot]

Pull request overview

This pull request addresses a REST regression (issue #3662) where OData system query options like $filter / $orderby could fail to be extracted from the query string, by normalizing URL-encoded $ (%24) before downstream parsing.

Changes:

• Normalize %24 to $ in the REST request query string prior to parsing.
• Add an end-to-end REST test to validate requests using $filter and $orderby succeed.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
src/Core/Services/RestService.cs	Normalizes the raw query string so $-prefixed OData query options can be parsed reliably.
src/Service.Tests/Configuration/ConfigurationTests.cs	Adds an end-to-end REST test to prevent regressions for $filter / $orderby query options.

[souvikghosh04]

needs some changes on parsing logic and additional tests assesrtion

[souvikghosh04]

I don't think this explicitly tests the %24. the httpclient would internally normalize this, so this can pass with or without the fix. you might need to explicitly pass the encoded values in URI "/api/Book?%24orderby=id%20desc&%24filter=publisher_id%20eq%201234") and then do proper assertions.

[RubenCerna2079]

No, the whole point of the test is to make an end-to-end scenario with values that a user would use. Adding the encoded values directly would defeat that purpose and would not help us catch any possible regressions in the future. DAB should be able to encode these values by itself and not throw any errors.

[souvikghosh04]

the intent is fair but partially justifiable. this test doesn't hit the fix's code path. HttpClient won't percent-encode $ (it's a legal sub-delimiter per RFC 3986), so Request.QueryString never contains %24 here, the Replace calls never fire. you can verify by reverting the fix and confirming the test still passes.

DAB is the server. it doesn't encode. it decodes what arrives on the wire. The regression is specifically when a client sends %24filter. the test must send the encoded form.

Suggestion: keep both as [DataRow] inputs: the current URI as a smoke test, plus a %24-encoded variant as the actual regression guard.

[souvikghosh04]

shouldn't this be parsed using already available libraries instead of manually? we have something like this below context.RawQueryString = queryString; context.ParsedQueryString = HttpUtility.ParseQueryString(queryString); or using Microsoft.AspNetCore.WebUtilities.QueryHelpers.ParseQuery()

[souvikghosh04]

this should be solved/fixed at root level to ensure downstream usage of the querystring is already valid.

[souvikghosh04]

the trailing comment on RestService.cs:75 says what the code does but not why $ arrives URL-encoded in the first place, nor what PR #3080 changed that broke it. future readers will look at the Replace chain and have no idea whether they can remove it.

[souvikghosh04]

this only checks HttpStatusCode.OK. a regression where $filter is silently dropped would still return 200 with an unfiltered list. can we also assert that the response body contains the rows you expect (publisher_id == 1234 only) and in the order requested.