Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

case-folding of "ProductCode" field

Abierto
  • ¿Algo no está bien?
#166 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
42/100
Tipo de issue
Documentación
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
csharp
Área
api, documentation

Línea de trabajo

Comienza en el endpoint /manifestSearch de la fuente REST y rastrea cómo se comparan las solicitudes de ProductCode con MatchType Exact, utilizando los ejemplos en minúsculas y el comportamiento de la fuente oficial descrito aquí. Se considera terminado cuando el comportamiento esperado de normalización y coincidencia de ProductCode queda establecido y documentado para los implementadores de fuentes REST.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Issue-Docs
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!

Lenguaje dominante
C#
Estrellas
317
Forks
79
Merge medio
8 h 42 min
PR fusionados (30 d)
6

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de microsoft/winget-cli-restsource

Todos los issues de microsoft/winget-cli-restsource

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.