Fix failure on REST requests with $filter and $orderby parameters#3664
Merged
Conversation
1 task
Contributor
There was a problem hiding this comment.
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
%24to$in the REST request query string prior to parsing. - Add an end-to-end REST test to validate requests using
$filterand$orderbysucceed.
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. |
anushakolan
approved these changes
Jun 12, 2026
souvikghosh04
requested changes
Jun 15, 2026
souvikghosh04
left a comment
Contributor
There was a problem hiding this comment.
needs some changes on parsing logic and additional tests assesrtion
souvikghosh04
approved these changes
Jun 17, 2026
souvikghosh04
left a comment
Contributor
There was a problem hiding this comment.
LGTM. thanks for addressing the comments.
souvikghosh04
approved these changes
Jun 17, 2026
RubenCerna2079
added a commit
that referenced
this pull request
Jun 18, 2026
) ## Why make this change? - Fix issue #3662 This issue is caused by a regression in PR #3080 The regression is that we start using the raw encoded URL and we assume that the `$` character is not encoded when using the `ExtractRawQueryParameter` function, this is half true, since depending on where the URL comes from it will encode it or it will treat it as a special character and leave it as it is. This means the function looks for the `$filter` or `$orderby` when the URL has the possibility to change them to `%24filter` or `%24orderby` which causes the failure. ## What is this change? This change fixes a bug that caused using `$filter` or `$orderby` in REST. This is done by encoding the `parameterName` so that it has the same format as the raw URL, it will only change it if it is unable to find the original `$` character in the raw query. ## How was this tested? - [ ] Integration Tests - [x] Unit Tests Added end to end test to ensure that REST requests that use `$filter` and `$orderby` succeed for both cases where a user uses the special character `$` or its URL encoded format `%24`. ## Sample Request(s) http://localhost:5000/api/Book?$orderby=id desc http://localhost:5000/api/Book?$filter=publisher_id 1234
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why make this change?
This issue is caused by a regression in PR #3080
The regression is that we start using the raw encoded URL and we assume that the
$character is not encoded when using theExtractRawQueryParameterfunction, this is half true, since depending on where the URL comes from it will encode it or it will treat it as a special character and leave it as it is.This means the function looks for the
$filteror$orderbywhen the URL has the possibility to change them to%24filteror%24orderbywhich causes the failure.What is this change?
This change fixes a bug that caused using
$filteror$orderbyin REST. This is done by encoding theparameterNameso that it has the same format as the raw URL, it will only change it if it is unable to find the original$character in the raw query.How was this tested?
Added end to end test to ensure that REST requests that use
$filterand$orderbysucceed for both cases where a user uses the special character$or its URL encoded format%24.Sample Request(s)
http://localhost:5000/api/Book?$orderby=id desc
http://localhost:5000/api/Book?$filter=publisher_id 1234