I think this would be reasonable to support. The only downside is that it prevents using the query string for any neuroglancer-specific parameters. But instead precomputed://...#parameter=value can be used for that purpose.

As I was messing around with this, I also discovered a bug (or maybe a feature, depending on how you look at it), so I figured I'd ask before I submit a PR.

the resolvePath function in src/neuroglancer/datasource/precomputed/frontend.ts can be exploited by a carefully generated info. I discovered this when I was trying to get my server to generate a "patched" version of a precomputed chunks info that resided on a third party server, and that still directed Neuroglancer to fetch the tiles from that third party server (instead of fetching them from my own server). I eventually found that setting the scale.key to something like ../../../../../http://third-party-server/path/to/scale would achieve just that. Following is a working example:

resolvePath("http://example.com/some/path", "../../../../../http://somewhere-else/some/other/path")
// resolves to "http://somewhere-else/some/other/path"

Now, this works, but doesn't look at all like something I should be doing. It is useful in some cases, though. I haven't given too much thought to the security implications, but in principle it seems that the scale keys could work just like any other URLs on HTML elements: relative paths would be relative to the path of the info file, absolute paths would start from the info file domain, and paths with a preceding protocol would be able to point anywhere on the web, including other domains. And then resolvePath would handle all of those cases gracefully. I understand, though, that this would change the precomputed chunks spec in a way what might be backwards-incompatible.

I still managed to achieve what I was trying to do by awkwardly redirecting every request for a tile to the third-party URL where that tile resides, but that introduces one unnecessary round trip and is some more pointless load on my server.

Any thoughts on that?

This was indeed not intended functionality. I don't think there is any security risk in Neuroglancer, since neuroglancer supports only read access, but I think it would be better not to allow it in order to avoid incompatibility with other implementations.

If this were supported by implementations like tensorstore that support writing, it could be used similarly to a symlink attack to overwrite unintended data, though I suppose there could be an option to limit the allowed redirect destinations.

The other issue is that it would force other implementations to support the same protocols as neuroglancer. Neuroglancer currently supports some custom protocols like gs:// and gs+ngauth://, and it would be somewhat unfortunate to have to support these in other implementations. In tensorstore there is also an explicit key-value store abstraction, that the precomputed format is built on top of, and this redirect functionality doesn't really fit with that.

On the other hand potentially this redirect functionality could be documented as being supported exclusively by neuroglancer.