case-folding of "ProductCode" field

[jantari]

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!

[denelon]

@jantari, I believe the client is taking the product code from a given manifest and making it lower case. <- assumption

There is no requirement for a REST source to enforce a specific casing, which is why there is a Case Insensitive match. This may be interpreted a bug in the client behavior.

https://github.com/microsoft/winget-cli/blob/a394ea820386514ece1c88ce0af039db1d18251a/schemas/JSON/manifests/v1.4.0/manifest.installer.1.4.0.json#L354-L359

[jantari]

Thanks for confirming, I've subscribed to microsoft/winget-cli#2558