Getting unexpected error responses when using minSchemaVersion or maxSchemaVersion

[thepetk]

Which area this feature is related to?

/kind bug

Which area this bug is related to?

/area registry

What versions of software are you using?

Go project

Operating System and version: N/A

Go Pkg Version: 1.18

Bug Summary

While working on redhat-developer/alizer#226 I've experienced a 500 error when I've tried to use a URL params for minSchemaVersion and maxSchemaVersion. More detailed when I've tried to use a version older than 2.x or with 3 digits like 2.x.x I'm getting a 500 response.

This error might be existing due to this code: https://github.com/devfile/registry-support/blob/200b4f015149a2c23314ea2ef83711869e4d09c9/index/server/pkg/server/endpoint.go#L432

Adding this as a bug, as I would expect a 400 status code instead of 500. Additionally I think we should might add the range of accepted versions here: https://github.com/devfile/registry-support/blob/main/index/server/registry-REST-API.adoc#query-parameters

To Reproduce:

Reproduces error for passing three digit devfile version:

curl -o - -i http://devfile-registry.192.168.1.1.nip.io/v2index?minSchemaVersion=2.1&maxSchemaVersion=2.1.9

Reproduces unexpected 500 internal server error:

curl -o - -i "https://registry.devfile.io/v2index?minSchemaVersion=1.1&maxSchemaVersion=1.4"

Expected behavior

1. I was expecting a 400 status code response in case of not accepted URL query param.
2. I was expecting to be able to use the full devfile version number.

Any logs, error output, screenshots etc? Provide the devfile that sees this bug, if applicable

Additional context

Any workaround?

None.

Suggestion on how to fix the bug

Fix validation to allow the optional use of the bugfix part of the devfile version number and the response for invalid request parameters should be changed from 500 internal server error to 400 bad request.

Target Date: 06-27-2023

[thepetk]

I've added the blocked label to redhat-developer/alizer#226 as it requires first to have this issue completed

[michael-valdron]

Schema version validation error responses now will return error code 400 bad request instead of 500 internal server error. In addition, the API endpoints now will allow both 2.2 and 2.2.0 for the schema version parameters. devfile/registry-support@9e8694b

[michael-valdron]

Added test cases for these changes and an open PR is ready for review: devfile/registry-support#174