I think it should be worth mentioning that this is normally done in place of the normal call to .../uploads/ to start a blob upload. So if a registry does not support cross repository mount, it will return a normal 202 and the client will continue the upload (not reissue the request without the mount param).

Did we have 201 listed as valid return code for /uploads without mount for a reason? Or was that just listed because of this. We should be explicit about the difference between 201 and 202 here.

@dmcgowan based on yesterday's call, we have decided to require cross-repository mount, making the distinction between 201 and 202 unnecessary here -- it will always be 201 unless the source blob is not found, in which case it will be 404.

I have pushed a new commit removing 405 as an acceptable status code, thus requiring cross-repository implementation.

Allowing both 201 and 202 on /uploads was a compromise solution based on what existing registries were already doing -- see #171 and @jdolitsky 's comment on #68

I've written several clients that rely on the fact that 201 means the mount succeeded and 202 means continue with the upload -- ideally registry behavior would be consistent here. I don't think requiring cross-repo mount invalidates the requirement of this distinction.

unless the source blob is not found, in which case it will be 404

This would also slow down uploads because you'd require an additional roundtrip to start the upload process if the mount fails.

@jonjohnsonjr This is my proposed solution:
In the first test, allow either a 201 or 202. If 201, a fetch for the blob will be tested to ensure its existence. If 202, we will verify that a valid <session-id> is returned.

If I'm getting it right, this should satisfy the requirements -- please let me know if there's anything further I should know about before making changes.