spacecookie

spacecookie copied to clipboard

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.

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...

2. 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!