buffer.uri / image.uri validator accepting non-relative uri only, and not resources served over http(s)

[xgui3783]

Hi all,

Firstly, thank you very much for the plugin, it has made the workflow much much easier.

I was working with a project where binary resources easily adaptable to gltf format already exists and are served over https. After generating buffer.uri with values such as http://localhsot:3001/buffer, the validator complains about NON_RELATIVE_URI.

Is it an anti-pattern to serve buffer uri/image uri over http(s)?

coincidentally, gltf previewer, babylon.js does not load the buffer.uri served over http, but threejs does.

[lexaknyazev]

It's not an anti-pattern per se, since the validator issues a warning, not an error. The reasoning is simple: not all clients will acquire external resources from URIs with explicit schemas (be it http:// or file://), so such assets are less portable. Of course, application-specific use cases for absolute URIs are valid.

As for babylon.js not loading resources over http, it may be an issue with VSCode plugin or Babylon.

/cc @emackey @bghgary

[emackey]

@xgui3783 If you're seeing this in VSCode, you can configure your settings.json file (for the user, or for the workspace) to ignore a particular warning. For example:

    "glTF.Validation.ignoredIssues": [
        "NON_RELATIVE_URI"
    ],

I did notice that my VSCode hookup of the validator isn't willing to fetch remote resources like this (I think I'm doing a simple file open on the uri, not a network request). But I'd be hesitant to change this as I'd worry about the security implications of allowing local glTFs to request arbitrary remote resources on behalf of the user. So I think I'll leave that behavior in place, unless there are strong reasons to change.

Having the previewer do it is somewhat safer, as that's in a sandboxed webview. Not sure why Three works and Babylon does not.

[lexaknyazev]

But I'd be hesitant to change this as I'd worry about the security implications of allowing local glTFs to request arbitrary remote resources on behalf of the user.

This could be a plugin setting (off by default) that allows http://localhost requests since it's pretty common among web developers. Optionally, it could be extended with a list of allowed domains.

[bghgary]

Not sure why Three works and Babylon does not.

Babylon assumes urls are relative by default. It will not work with absolute urls without custom settings.

[xgui3783]

Hi all, thanks for your explanations.

But I'd be hesitant to change this as I'd worry about the security implications of allowing local glTFs to request arbitrary remote resources on behalf of the user.

this makes perfect sense.

Babylon assumes urls are relative by default. It will not work with absolute urls without custom settings.

noted.