Discourage use of fragment in URI

[lexaknyazev]

Since we treat image.uri and buffer.uri as "URI" by RFC3986, we should explicitly discourage cases like this:

{
  "images": [
    {
      "uri": "image#2.png"
    }
  ]
}

When filename contains # symbol, it must be encoded as a part of path:

{
  "images": [
    {
      "uri": "image%232.png"
    }
  ]
}

[donmccurdy]

This may be mixing terms slightly — the fragment identifier is only one example of a broader case. Unless there's something specific about fragment URIs that presents a problem?

Bad:

• image#2.png
• image?2.png

Fine:

• image.png#v=2
• image.png?v=2

I think what we should clarify is that authoring tools — not client implementations — are responsible for correct URI-encoding. If a ? or # is in the URI, it should be treated as a query or fragment parameter respectively by the client.

[lexaknyazev]

Unless there's something specific about fragment URIs that presents a problem?

I'd say that while query parameters may be fine for web usage, fragment URIs make zero sense for images and binary buffers.

If a ? or # is in the URI, it should be treated as a query or fragment parameter respectively by the client.

Agree in general. This will work for URI schemes that support query and fragment parameters, but this could be a problem for relative URIs that meant to be used in different contexts, e.g., using the same glTF asset on web and on desktop: query and fragment parameters don't exist for file:// scheme (RFC 8089).

---

Maybe, we should also refine language around "relative", because, by RFC 3986 definition, relative URIs can have absolute path. Consider something like this:

{
  "images": [
    {
      "uri": "/image.png"
    }
  ]
}

[donmccurdy]

I'd say that while query parameters may be fine for web usage, fragment URIs make zero sense for images and binary buffers.

Fragment URIs are not passed to the server, but they are passed to Service Workers (JS workers that run apart from the main thread, and often handle resource caching). That's an unlikely use case, I admit, but since we want to support query parameters anyway I think it would be ideal to treat both the same way.

Maybe, we should also refine language around "relative", because, by RFC 3986 definition, relative URIs can have absolute path.

+1, good point.

[lexaknyazev]

Fragment URIs are not passed to the server, but they are passed to Service Workers...

Fair point, let's treat query and fragment alike.

[lexaknyazev]

@donmccurdy
Please review updated URI section.

[donmccurdy]

I'm not quite clear on how to interpret this — we're saying that these things (absolute URI schemes, query and fragment parameters, ...) are invalid glTF, but (according to implementation note below) that clients can choose to support them anyway?

Or do you mean to say, clients must support at least relative URLs that don't include query/fragment, but may also choose to support more? And therefore authoring a glTF with query/fragment is not invalid, just less portable?

[lexaknyazev]

This one:

Or do you mean to say, clients must support at least relative URLs that don't include query/fragment, but may also choose to support more? And therefore authoring a glTF with query/fragment is not invalid, just less portable?

However, I think that usage of query/fragment should issue validation notice. Could you refine PR language so that intention is clear?

[donmccurdy]

How about:

• Relative URI paths — or path-noscheme as defined by RFC 3986, Section 4.2 — without scheme, authority, or parameters. Reserved characters must be percent-encoded, per RFC 3986, Section 2.2.

  Implementation Note: Clients can optionally support additional URI components. For example http:// or file:// schemes, authorities/hostnames, absolute paths, and query or fragment parameters. Assets containing these additional URI components may be less portable.

[alteous]

In the Rust gltf crate we sometimes return a special #bin fragment, meaning the BIN section binary glTF. Is this sort of behaviour discouraged?

[lexaknyazev]

@alteous
This section applies to JSON contents, it doesn't define runtime behavior.
However, I can see an issue with returning #bin. Let's say that some application uses custom URI resolver that relies on fragments, while GLB asset has both internal BIN section and an external binary buffer which has #bin as its buffer.uri. In such case (probably extremely rare), it may be hard to avoid ambiguity.

[pjcozzi]

I think what we should clarify is that authoring tools — not client implementations — are responsible for correct URI-encoding.

Spec language is up to you guys, but I agree with the idea.

Merge when ready.

[lexaknyazev]

@donmccurdy @bghgary
OK to merge?

[bghgary]

This looks fine to me.

Speaking of URIs, should we also disallow referencing parent files (e.g. using ../../..)? This was brought to my attention during a security pass.

[donmccurdy]

... should we also disallow referencing parent files (e.g. using ../../..)?

It should not be part of the two cases clients must support, I think, and should be considered "less portable". But i'm not sure about disallowing it entirely.

[lexaknyazev]

We should definitely add a note about security concerns (e.g., loading an asset with parent paths from untrusted source). I'm not sure about disallowing such URIs on spec level.

Also related: should we encourage normalization on export (e.g., dir1/./dir2/../tex.png to dir1/tex.png)?

[bghgary]

should we encourage normalization on export (e.g., dir1/./dir2/../tex.png to dir1/tex.png)?

In other words, canonicalized paths. I say yes, especially if caching is happening using this URI.

[emackey]

Looks like this got a green light but was never actually merged. Still OK to merge?

[lexaknyazev]

@emackey We can merge this as is, or enhance it with language about URI normalization first.

[emackey]

I think this is good to go. If anyone wants to change the language further, feel free to open a new PR.