case-folding of "ProductCode" field

Brief description of your issue

Hi,

for implementing my own REST-source I have found the schemas and some of the code provided in this repository very helpful.

However one thing that is not clear to me is how the REST source is expected to act in regards to ProductCode normalization of the client (winget CLI).

If we look at some public and working manifests from the winget-pkgs repo, such as:

Telerik.Fiddler.Classic
Clement.bottom

we can see that they specify the ProductCode as a string containing uppercase letters. In my REST-source I ingest these exact same manifest files into my data model to be queried by winget clients.

When doing a winget list operation, the winget CLI sends a lot of API POST requests to the /manifestSearch endpoint, looking for matching packages for the ARP (add-remove-programs) entries it finds on the local computer. For the local ARP entry of the program "Fiddler", this API request carries the following body data:

{
  "Inclusions": [
    {
      "PackageMatchField": "ProductCode"
      "RequestMatch": {
        "KeyWord": "fiddler2"
        "MatchType": "Exact"
      }
    },
    {
      "PackageMatchField": "NormalizedPackageNameAndPublisher"
      "RequestMatch": {
        "KeyWord": "progresstelerikfiddler"
        "MatchType": "Exact"
      }
    }
  ]
  "Filters": []
}

as we can see, winget-CLI appears to lowercase the ProductCode before sending the API request, but at the same time specifies a MatchType of Exact instead of CaseInsensitive - so, in my current implementation, my REST source dutifully returns back 0 matches. I have observed the same behavior with full-on GUIDs such as the one the Clement.Bottom package uses. Winget-CLI queries for the correct GUID, but in all-lowercase with MatchType Exact - leading to no matches being found.

However, when I query the official winget source I do get matches for these programs back.

So my question is whether a REST source is expected to normalize all ProductCodes to lowercase on ingest (despite the fact that a CaseInsensitive MatchType also exists?) or whether I'm misinterpreting what I'm seeing.

If this is the case and ProductCodes are to be normalized server-side, it would be great if this could be documented.

Thank you!

Start at the REST source's /manifestSearch endpoint and trace how ProductCode requests with MatchType Exact are compared, using the lowercased examples and the official source behavior described here. Done means the expected ProductCode normalization and matching behavior is established and documented for REST-source implementers.