Update spec language to support pushing multiple tags at once

[jcarter3]

Also can be used when pushing tags for a non-canonical algorithm (sha-512, blake3)

Implements #591

[sudo-bmitch]

My personal preference is to allow a registry to respond with an error if a limit is exceeded and have the spec identify a minimum that registries are expected to support, similar to how large manifests are handled.

[jcarter3]

The issue I see here is that if a client passes 100, but the registry only supports 25, then the client has no way of knowing if the other 75 failed for error, or if there was a limit. We could set this as something reasonably high enough (100?) so that it would rarely happen in practice. Or also add an OCI-Tag-Limit response header to indicate the max so that the client could intelligently batch. But the thinking here is that this can make both the registry and the client much more efficient with validations and network calls, so as long as it's a valid URL length, it should work.

[sudo-bmitch]

so as long as it's a valid URL length

What's an invalid URL length?

[jcarter3]

This seems a bit tricky to nail down as it's all over the place. Browsers seem to support a lot, like in the 65,000-100,000 character range. (>500 tags at max tag length). Some security recommendations say to limit it to 1k-2k on webservers to prevent some kinds of attacks, which is more like a max of 10 tags at a time at max tag length.

Maybe it should be updated to say it MUST support a minimum of 10, SHOULD not set an upper limit.

[sudo-bmitch]

Yeah, I'm not finding a limit in the http RFCs. In Go, the limit defaults to 1MB for net/http Server.MaxHeaderBytes which includes all headers and the request, but that is configurable. I'd say registries SHOULD support at least 10 tags per request. If a registry rejects the request for exceeding a tag limit, it MUST return a 414 Request-URI Too Long, and clients MAY retry with fewer tags.

If they hit the Go limit, that throws a 431 Request Header Fields Too Large, which we should document as another possible error.

I hesitate to respond with an OCI-Tag-Limit header because the 414/431 could be from different causes, including a proxy or the internal Go http server, and it may be from other headers, the overall URI length, or a fixed limit on the number of tags enforced by the registry implementation.

In practice, I think most users would rarely exceed 5 tags per manifest (3 tags for semver + a fixed/latest tag or two), so I don't think a failure or split+retry is going to impact folks doing normal things.