Open RichardTea opened 1 year ago
Space and percent have to be percent-encoded.
RFC 3986 separately states that "%" MUST be encoded as "%25", but it is unclear from the text whether or not this requirement also applies to glTF
glTF URIs are normal URIs, all the normal rules apply.
"%" is an ASCII character, and is not an RFC 3986/3987 reserved character, so the text indicates that it MAY be written as-is
I don't see how it indicates that. The text says reserved characters have to be percent encoded and says non-ASCII characters may be written multiple ways, but neither applies to percent.
Sadly I am aware of implementations that export using all six methods - Blender's Khronos glTF Blender I/O v1.5.17 even does this in the same file!
If you can reproduce a wrongly encoded URI in the current version, you should report a bug.
Some strongly related discussion (with a table that shows possible ambiguities that is very similar to the one on the first post here) can be found around https://github.com/KhronosGroup/glTF/issues/1449#issuecomment-611560284 .
Space and percent have to be percent-encoded.
The trouble is that the published document does not actually say that.
I note that the linked issue it's explicitly noted that "space" can be either encoded or unencoded. https://github.com/KhronosGroup/glTF/issues/1449#issuecomment-422862486
I'm fine with a rule along the lines of "if nothing else needs to be percent-encoded then space may be left as-is", but any paths containing the "%" character absolutely must be encoded.
glTF URIs are normal URIs, all the normal rules apply.
I agree that the intent probably was that glTF URIs MUST be either URIs (RFC 3986) or IRIs (RFC 3987). Unfortunately, the text is ambiguous and a large number of implementations do not encode the % character.
If you can reproduce a wrongly encoded URI in the current version, you should report a bug.
Snippet from a Khronos glTF Blender I/O v3.4.50 export:
"buffers" : [
{
"byteLength" : 840,
"uri" : "example 10%.bin"
}
]
Section 2.8 URIs is unclear. It does not appear to be possible for an implementation to determine whether a URI has been percent-encoded or written as-is.
":" / "/" / "?" / "#" / "[" / "]" / "@" / "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
Additionally:
RFC 3986 separately states that "%" MUST be encoded as "%25", but it is unclear from the text whether or not this requirement also applies to glTF - "%" is an ASCII character, and is not an RFC 3986/3987 reserved character, so the text indicates that it MAY be written as-is.
It is not possible for a reader to distinguish between cases 2 and 3, or between cases 5 and 6. A compliant reader must try both URIs (perhaps re-encoding for HTTPS)
I recommend two changes:
a) The wording of the first requirement for relative paths should be changed to:
b) The glTF standard should explicitly require paths containing the "%" character be percent-encoded. This would prohibit cases 3, 4 and 6, and eliminate the confusion.
Sadly I am aware of implementations that export using all six methods - Blender's Khronos glTF Blender I/O v1.5.17 even does this in the same file!