Unsure if this is by design, but it definitely confused me. Uplink displays the share url, then when followed, shows an Oops on the website. Suggestion is, if it’s by design, it might be a good idea to display a message like:
Note: this object does not yet exist
after the URL is displayed as a heads-up.
Yes, it’s by design. You can generate a link before the bucket/path/objects are created. It can be useful for configuration purpose (you generated the static share URL and provided it to your application or site without writing even a one line of code).
It can definitely be confusing.
For me the starter reason I did not do this check in the library is that it would require a round-trip to the sattelite. And like Alexey said it can be useful.
I’m open for some improvement, only not sure what form that would take.
I don’t think doing it in the library is necessary. If someone is using the library directly, they should understand more what they are doing.
But for someone using the uplink CLI to share an object, I think they would appreciate a check to see if the object is accessible at the URL created since the whole purpose is to let someone else access the object. So rather than create an incorrect URL because of a typo (my case) and give it to people in email, give it to a web design group, make it live on a site, etc., the uplink CLI could do an HTTP head request to see if it gets a 200 (success), 404 (not found), or some other status and tell the user:
Test fetch of URL was successful, object size is 24MB (for 200)
Object is not yet loaded at this URL (for 404)
Object is not accessible at this URL: error status 403 Forbidden
etc.
I appreciate trying to optimize performance, but in this case, it took me a few minutes to realize what had happened after doing a couple of reloads and getting 404 errors. So I ended up doing extra round trips anyway! 
We are working on this now for other reasons so I’ll see what I can do.