Auto blocking may not work reliably for remotes which HTTP redirect or where Remote URL base path access is not allowed

Problem

Proxy repository automatic blocking feature status check hits the root of the configured remote URL instead of the root of the actual Remote URl.

Example: Spring.io

Configure a proxy repository to https://repo.spring.io/libs-release/ . The automatic blocking status check will send a HEAD request to https://repo.spring.io which returns a 500 response. This will autoblock the repo because 500 status code is one of the status codes NXRM considers as the remote is broken.

Example: Microsoft docker registry

For a Docker registry and some other formats this does not make sense as a reliable status check.

For example if the remote to be proxied is https://mcr.microsoft.com , then NXRM will make a GET request to

https://mcr.microsoft.com

which 301 perm redirects to

https://aka.ms/mcr

which 301 perm redirects to

https://github.com/microsoft/containerregistry

If any one of those requests fail, the repo is autoblocked. However none of those GET requests prove the remote can work as a docker registry, which typically only needs request to work at paths under https://mcr.microsoft.com/v2 or https://mcr.microsoft.com/v1 .

Workaround

If a repo is being auto-blocked incorrectly, the user should disable auto blocking on the repo settings page.
However this risks impact to NXRM should the remote be legitimately become unreachable.

Expected

Implement a reliable repo status check endpoint default for each format. Alternately provide a custom endpoint that can customized by the administrator.