CC +brettw, mkwst as //url OWNERS

Do you think this would be reasonable thing to support? Or would it be too much of a special case / too tightly coupling Chrome with details of a non-standard scheme?

Oh, I guess there are actually a few different URL endpoints that might make sense, depending on if things are public or pointing to objects vs buckets, or for writing vs reading

https://console.cloud.google.com/storage/browser/<bucket-name>/
https://storage.cloud.google.com/<bucket-name>/<object-name>
https://storage.googleapis.com/<bucket-name>/<object-name>

(Based on docs in https://cloud.google.com/storage/docs/cloud-console#_sharingdata)

It's not really clear to me why adding this scheme would be valuable. Can you spell out the rationale?

I think we're pretty unlikely to tie //url to a Google-specific scheme pointing to a Google-specific endpoint. It's certainly possible for an embedder to create this kind of linkage (Chrome does so for `chrome-extension://` for instance), but there are fairly deep implications to doing so (especially if it's just a wrapper around HTTP to a web endpoint). As the tip of the iceberg: what cookies do we send along with requests?

The value-add is admittedly pretty small. I come across gs:// references ~weekly that I want to explore, and it's somewhat tedious to do the gs:// -> https://storage.cloud.google.com/ conversion manually. It would be a delight to just copy/paste the link into the omnibar and have it just work.

Perhaps this would better be suited as a feature of Chrome (where it might make a bit more sense to have such a Google-specific tie), and not something tied into //url itself.

I would imagine the cookies would be the same as if someone were navigating directly to https://storage.cloud.google.com/x/y/z

Normally extensions have to be triggered by the extension keyword name and then a space or tab, so an normal extension won't work.

Could you make an extension that looks for navigations to a search results page with a search "gs://" and instead redirects the user to the appropriate endpoint?

I'm skeptical that gs:// is a general enough need that we want to special case it into Chrome.  (Do other cloud platform providers also have funky URL schemes like that?)

This is the sort of thing where, rather than implement as a Chrome extension, it probably makes more sense to register an OS-native handler for these that just shellexecutes the correct underlying HTTPS URL.  This way links in any program should Just Start Working.  Registering such a handler could be done via a batch file or something.

There's an existing Chrome bug that in such a case, the omnibox still won't handle this correctly, which we really should fix.

On re-reading, I agree with pkasting@.  If you want gs:// URLs to work, you should register that protocol at the OS level.  Making Chrome-specific hooks for this protocol seems like the wrong thing to do.