This issue comes in two parts, both regarding the result of collection queries, but due to different queries:

1.

If the contents of a collection query after /ws/2/collection is invalid, then the query is interpreted to be just this query (which gets the list of a user's collections [and therefore requires authentication]). Some examples of queries which should have different error cases:

• GET /ws/2/collection/29611d8b-b3ad-4ffb-acb5-27f77342a5b0 (no type set - it should be 'artist')
• GET /ws/2/collection/29611d8b-b3ad-4ffb-acb5-xxxxxxxxxxxx/artists (not a uuid)
• GET /ws/2/collection/c1f75626-bff2-499d-b8f3-1a8ade05cb70/artists (not a collection that exists - 404?)
• GET /ws/2/collection/29611d8b-b3ad-4ffb-acb5-27f77342a5b0/releases (not a release collection)

It may be important to not leak the existence of a collection by having a different response for no collection and private collection.

This is related to part of MBS-3125

2.

Related to above, if a PUT query is made to add an item to a collection:

PUT /ws/2/collection/29611d8b-b3ad-4ffb-acb5-27f77342a5b0/artists/10adbe5e-a2c0-4bf3-8249-2b4cbf6e6ca8?client=foo-0.1

but because artist PUT methods are not implemented (MBS-8459) this reverts to a collection list, which is doubly broken (I would expect to see a status message for any PUT request, not the result of a GET).
This is the same as the DELETE requests for removing items from collections.