conformance: LIST tags with n=0

[rchincha]

To get the next n entries, one can create a URL where the argument last has the value from tags[len(tags)-1]. If there are indeed more results, the URL for the next block is encoded in an RFC5988 Link header, as a "next" relation.

However, conformance tests are testing for n=0 case.

So, for tags list with n=0, what is the expected response? we return nothing because n=0, but "last" needs to be set because there are indeed more, but since nothing was returned, how does one set "last"?

With n=0, this requirement cannot be met as it is stated

[rchincha]

IMO, not sure how useful n=0 really except for checking if a "repo name" is present.

[eyJhb]

Shouldn't this match for catalog as well? Not allowing 0 makes sense.

[dmcgowan]

@eyJhb catalog is no longer covered by this spec. Generally the decisions made here for tags/list could apply there in implementations.

If we are going to test for the n=0 case, then we should make the behavior explicit. If the behavior is ignore n=0, then just test that it is ignored. If n=0 just returns an empty result, then no Link should be set, since this would lead to non-converging link following based on the current rules of reusing the n from the request.

[jdolitsky]

Copying text from this comment: distribution/distribution#3143 (comment)

Okay, so what I think should happen is the following.

• n=0 will return a empty list, and will not include a Link, as there are no more entries (depends on how you look at it. But if I want 0 and I want more, I will still get 0).

• last will be used to find the entries lexically after it, and the index does not need to exists.

  • this could bring some weird bugs for some people regarding encoding. but it does make sense to be able to search like this.

• last can stand on its own without n, as to use the default n value from the server (which it may impose).

This language should be clarified in spec

[jdolitsky]

Resolved by #206