Remove ns query string from URI when submitting requests to upstream.

[theodiem]

As mentioned on #5:

While I was writing some regex rules in traefik (which i configured in front of oci-registry), so I could forcefully "support" the ?ns={namespace} query ... I've noticed other manifests failing.
For example:

• works : curl "https://gcr.io/v2/kaniko-project/executor/manifests/v1.9.1-debug"
• doesn't work: curl "https://oci-registry:8080/v2/kaniko-project/executor/manifests/v1.9.1-debug?ns=gcr.io"
  Maybe because: curl "https://gcr.io/v2/kaniko-project/executor/manifests/v1.9.1-debug?ns=gcr.io" also returns a 404? ....

Originally posted by @theodiem in #5 (comment)

I can confirm by disabling TLS on upstreams.yaml and sniffing the traffic, that ns query parameter gets sent to upstream and some servers (at least gcr.io) returns a 404 if you query data with it. It works fine without it.

[mcronce]

Interesting find - thanks for the report! I was using this for gcr.io images extensively at my former job, but as of today can't find a single image on gcr.io that pulls successfully. I'll dig in further and see if there appears to be any nuance to it; worst case, I'll exclude ns when hitting gcr.io

[theodiem]

I haven't used many, just stumbled when submitting my kaniko builds to my (local) cluster instead of doing locally.
Maybe having as a flag that you can set in upstream.yaml? Things like test $upstream = "gcr.io" && mangle_url unsettles my heart ;)

[mcronce]

Just pushed a fix for this with 3c62c24; I had code to handle it, but a dependency update broke the functionality. I'll spin a release today, hoping to fix at least one of the other open issues first.

[theodiem]

I can confirm it works for me. Many thanks.