Fix #1055: Do not throw when ODataQueryOptions constructor receives whitespace query param keys#1540
Fix #1055: Do not throw when ODataQueryOptions constructor receives whitespace query param keys#1540axnetg wants to merge 2 commits intoOData:mainfrom
Conversation
|
@microsoft-github-policy-service agree |
| else | ||
| { | ||
| if (IsSupportedQueryOption(key)) | ||
| if (!string.IsNullOrEmpty(key) && IsSupportedQueryOption(key)) |
There was a problem hiding this comment.
Is it acceptable for the OData endpoint to allow an empty or whitespace-only query option, such as:
GET http://server/service/Customers?%20
Throwing an exception in this case seems reasonable.
There was a problem hiding this comment.
Hi @WanjohiSammy. I think avoiding the throw is the right choice here, since this is something a client can trigger and it currently results in an internal server error in the controller action, which doesn’t feel appropriate. This also makes the behavior consistent with EnableNoDollarQueryOptions = false, where unknown or empty keys are already ignored.
There was a problem hiding this comment.
@axnetg Please add an E2E test for this scenario. You can update the existing TestOrderBy_WithDifferentPropertyCase or any other tests by including cases like:
...
[InlineData("/books?orderby=ISBN&top=1&%20=foo&%20=%20")]
...
public async Task TestOrderBy_WithDifferentPropertyCase(string requestUri)
{
...
}|
@WanjohiSammy Done! |
Fixes #1055.
When
EnableNoDollarQueryOptionsis set to true and an OData endpoint receives a query string containing empty or whitespace-only keys, theODataQueryOptionsconstructor would throw an exception. This happened because, with this option enabled, the code attempted to process all keys using theIsSupportedQueryOptionmethod, which throws on empty input. WhenEnableNoDollarQueryOptionsis false, the logic only processed keys starting with '$', so empty strings were immediately discarded and did not cause an exception.This PR updates the query string parsing logic to ignore any query string keys that are empty. This ensures that only valid keys are processed as query options. The fix is backward-compatible and does not affect the handling of valid query options.
Let me know if you need further adjustments!