Open hyperrealgopher opened 3 years ago
I don't think that is possible: The gopher server never sees the /<filetype>/
part of a gopher URL since that is not part of the selector. It only exists to tell the client how to interpret the linked document.
gopher://host/1/foo/bar
makes a client send the selector /foo/bar
to host
, so there is really no way for us to figure out that we need to return a proper menu.
When i use the gopher
client I see this in the spacecookie
log:
[29/May/2021:23:42:10 -0700][info] New Request "/1/tag_list/" from [redacted]
UPDATE: nevermind, gopher
breaks when I do the above. waffle
does the behavior as expected (as you described). It's been a while since I touched gopher stuff directly. I see the problem...
- The gopher selector string. Note that some gopher selector strings begin with a copy of the gopher type character, in which case that character will occur twice consecutively. Also note that the gopher selector string may be an empty string since this is how gopher clients refer to the top-level directory on a gopher server.
https://www.w3.org/Addressing/URL/4_1_Gopher+.html
So this is a conventional thing some servers or administrators do, but we can't really rely on it. Also I don't want to heuristically take that into account, in case someone wants to have a normal /1
directory.
In this case, would it be possible to add a file extension or something which would enable the .gophermap
parsing behavior on arbitrary files? Or even a file prefix like GOPHERMAP_
?
In this case, would it be possibel to add a file extension or somethign which would enable the .gophermap parsing behavior on arbitrary files?
I guess we could do it for any foo.gophermap
, of course then .gophermap
would be part of the selector, but this way we wouldn't have problems with collisions.
Sounds like a great start to me!
Sometimes I want to have multiple gophermaps per directory and I want to use the
.gophermap
parsing behavior. I noticed I have to use "manually" written gophermaps if I want to have multiple gophermaps in one directory. The solution is to adhere to the RFC (I forget the number) convention on URIs in gopherspace, where/1/
in the beginning/as the prefix of the selector, for instance, denotes that the selector targets a menu and should be interpreted as such.My specific use case: In
burrow
I want to provide an index per phlog tag in separate menus, and I don't like that I would have to create a directory and a.gophermap
for each tag index in order to take advantage of the.gophermap
parsing behavior.