Repository navigation
File URIs with pointer fragments #665
Description
I'm not sure if this is a universal thing, but .Net apparently doesn't allow fragments for file:// URIs. It seems to URI-encode the # into the file name, making extracting a fragment difficult.
Ref: json-everything/json-everything#427
Is this something that we should have a test for?
Edit:
For a bit more information, my implementation combines the base URI with the $ref URI to get the full URI to resolve.
With a base URI of file:///c:/folder/file.json and a $ref of #/definitions/foo, that combining step (which uses .Net code, not mine) results in file:///c:/folder/%23/definitions/foo instead of file:///c:/folder/file.json#/definitions/foo; the file.json is replaced by the encoded # (%23) and it's now looking for a new file and fails to resolve.
Activity
Julian commentedon Apr 5, 2023
Sounds good to me, though I don't think we can represent that here at the minute, even in optional, as we don't have a way of assigning arbitrary URIs in the "core" test suite. (This is similar to why we don't have remote
$refURN URI tests). Could go into https://github.com/python-jsonschema/referencing-suite certainly, or we could of course revisit trying to figure out the least possibly invasive way to add tests like that.gregsdennis commentedon Apr 5, 2023
Can we not just add
"$id": "file:///c:/folder/file.json"to the schema? (Granted that's a windows file URI; maybe we need both.)Julian commentedon Apr 5, 2023
Oh I see, yes that definitely is a thing we can do. For some reason I assumed this was about retrieval URIs. +1
jdesrosiers commentedon Apr 5, 2023
Is it really correct that
file:URIs can't have fragments? Fragment is part of the generic URI structure. I think every scheme needs to at least allow them in order to be a valid URI.If fragments weren't allowed in
file:URIs, that would make them nearly useless with JSON Schema. A simple local reference to$defswouldn't be allowed. The only thing that would work would be an external reference with no fragment.gregsdennis commentedon Apr 5, 2023
It might just be a .Net thing. I don't know. Regardless, since at least one environment doesn't allow it (or at least treats them weirdly), it seems prudent to have a test to ensure they're supported.
joooeey commentedon Apr 18, 2023
RFC 3986 URI Generic Syntax appears to imply that a scheme specification (e.g.
file:) has no say in how to interpret fragments, so it can't forbid them:However, RFC 8089 The "file" URI Scheme
doesn't mention fragments at all. This makes sense from a purely logical perspective
but that way developers easily overlook
file:URIs may include fragments.Therefore it might not work well with all software.
Chrome and Edge correctly resolve the fragment in
file:///%HOMEPATH%/Downloads/RFC 3986_ Uniform Resource Identifier (URI)_ Generic Syntax.html#section-3.5
However, the file explorer manages to tell the browser to open the HTML but it doesn't scroll down.
So the test case is indeed sensible.