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.

[jcarter3]

I updated it to support 10 (still under a 1kb max URI), and defined additional error codes.

[tianon]

Should we do something with this example to make the RFC 2616 semantics more obvious at a glance? So that we don't get implementations that choke if every tag is a completely separate header, for example?

[sudo-bmitch]

I noticed there's a newer version of the RFC. So this updates that pointer and makes some, hopefully minor, tweaks.

[sudo-bmitch]

MUST feels a bit strong to me. My preference is for a SHOULD.

Suggested change

	1. MUST support pushing at least 10 tags at once
	1. MAY return a `414 Request-URI Too Long` status if more than 10 tags are pushed.
	1. SHOULD support pushing at least 10 tags per request.
	1. MAY return a `414 Request-URI Too Long` status if too many tags are included in the request.

[sudo-bmitch]

Slight reword and using rfc-editor.org for consistency with other parts of the spec, and pointing to the most recent version of the RFC:

Suggested change

	1. For each tag that was successfully pushed, include an `OCI-Tag` response header in accordance with [RFC 2616 (section 4.2)](https://datatracker.ietf.org/doc/html/rfc2616#section-4.2) semantics
	1. MUST include an `OCI-Tag` response header, in accordance with [RFC 9110 (section 5)](https://www.rfc-editor.org/rfc/rfc9110#name-fields) semantics, for each accepted tag.

[sudo-bmitch]

Suggested change

	OCI-Tag: 1.2.3, 1.2, 1, latest
	OCI-Tag: 1.2.3, 1.2, 1
	OCI-Tag: latest

[sudo-bmitch]

Suggested change

	The server would respond with the following header:
	The server could respond with the following headers:

[sudo-bmitch]

I've added a test for this in the conformance redesign (disabled by default, but enabled with the dev version): #588