Hi,
I have a question about the expected behavior of URIs in context of
browsing a site on a past commit.
Let's say we are on site 0xaaaa..., with HEAD of branch gwit_0xaaaaaaaa
being commit 00000. I browse to a doc on a previous commit, let's say
gwit://11111@self/index.gmi. Here I meet these links :
=> gwit://0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/article.gmi
=> gwit://self/article.gmi
=> ./article.gmi
=> /article.gmi
What happens when I click on one of these links ?
* should I go to
gwit://11111@0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/article.gmi ?
* should I go to
gwit://00000@0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/article.gmi ?
Here is how I see the answer, onsidering followinf sentence :
> When parsing such a URI, a gwit client MUST first replace self with the
> site identifier as described above
1. These links are equivalent and lead to HEAD of branch
gwit_0xaaaaaaaa, aka
gwit://00000@0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/article.gmi :
=> gwit://0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/article.gmi
=> gwit://self/article.gmi
2. relative paths always refer to the current commit, hence these links
lead to
gwit://11111@0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/article.gmi
=> ./article.gmi
=> /article.gmi
___
If my understanding is right, I think this sentence needs more examples
(if I understand RFC3986 right) :
> Resolving references (i.e. links) relative to a given base gwit URI
> works as specified in Section 5 of RFC3986
I suggest to append these examples :
```
# In context of page gwit://<VERSION>@<SITE>/
gwit://<VERSION>@<SITE>/foo/bar + baz (or ./baz) =>
gwit://<VERSION>@<SITE>/foo/baz
gwit://<VERSION>@<SITE>/foo/bar/ + baz (or ./baz) =>
gwit://<VERSION>@<SITE>/foo/bar/baz
```
___
If I am wrong, my question is : how to forge links indicating "navigate
to this file at the _current_ state of the gwit site" (you don't have
commit ID before commiting) , and links indicating "navigate to this
file at the _most recent_ state of the gwit site"
Hi, thanks for your observations! You're right in your interpretation of the
spec; see inline for more details.
tom.ngr@zaclys.net (2025-01-15 17:36:17 +0100) wrote:
> I have a question about the expected behavior of URIs in context of browsing
> a site on a past commit.
>
> Let's say we are on site 0xaaaa..., with HEAD of branch gwit_0xaaaaaaaa
> being commit 00000. I browse to a doc on a previous commit, let's say
> gwit://11111@self/index.gmi. Here I meet these links :
>
> => gwit://0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/article.gmi
> => gwit://self/article.gmi
> => ./article.gmi
> => /article.gmi
>
> What happens when I click on one of these links ?
>
> * should I go to
> gwit://11111@0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/article.gmi ?
> * should I go to
> gwit://00000@0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/article.gmi ?
>
> Here is how I see the answer, onsidering followinf sentence :
>
> > When parsing such a URI, a gwit client MUST first replace self with the
> > site identifier as described above
>
> 1. These links are equivalent and lead to HEAD of branch gwit_0xaaaaaaaa,
> aka gwit://00000@0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/article.gmi :
> => gwit://0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/article.gmi
> => gwit://self/article.gmi
>
> 2. relative paths always refer to the current commit, hence these links lead
> to gwit://11111@0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/article.gmi
> => ./article.gmi
> => /article.gmi
Yes, this matches the intent of the spec, as RFC3986 keeps the current
"authority" part of the URI (in our case, `[<VERSION>@]<SITE>`) when resolving
a relative link. This means that browsing a site containing relative links
should keep you "stuck" at the version where you started from, which looks to
me like the natural behaviour for a system where site versioning is relevant.
The gwit client may then ease "jumping" to the latest version of a page.
Please note that the `alt` config value rewriting a link like
`https://foo.bar/page.html` to `/page.html` instead of `gwit://self/page.html`
is consistent with this behaviour.
> ___
>
> If my understanding is right, I think this sentence needs more examples (if
> I understand RFC3986 right) :
>
> > Resolving references (i.e. links) relative to a given base gwit URI
> > works as specified in Section 5 of RFC3986
>
> I suggest to append these examples :
>
> ```
> # In context of page gwit://<VERSION>@<SITE>/
> gwit://<VERSION>@<SITE>/foo/bar + baz (or ./baz) =>
> gwit://<VERSION>@<SITE>/foo/baz
> gwit://<VERSION>@<SITE>/foo/bar/ + baz (or ./baz) =>
> gwit://<VERSION>@<SITE>/foo/bar/baz
> ```
I see how a clarification in the spec helps here, so I added one in commit
1e935e43 (with a single example to avoid some repetition). Thanks for the
suggestion!
> ___
>
> If I am wrong, my question is : how to forge links indicating "navigate to
> this file at the _current_ state of the gwit site" (you don't have commit ID
> before commiting) , and links indicating "navigate to this file at the _most
> recent_ state of the gwit site"
Your interpretation was right, but I'll include example links for both
behaviours, for the sake of completeness:
- Navigate to same state specified in URI being viewed: relative link (without
authority part): `sub/page.gmi` or `/top/sub/page.gmi`.
- Navigate to most recent state: absolute link (with authority part):
`gwit://0x.../top/sub/page.gmi`, `gwit://self/top/sub/page.gmi`,
`//self/top/sub/page.gmi`. No way to use a generic relative link here,
though the client may help.
Cheers!
--
Ivan Vilata i Balaguer -- https://elvil.net/