sternenseemann / spacecookie

gopher library & server written in Haskell
https://sternenseemann.github.io/spacecookie/
GNU General Public License v3.0
47 stars 5 forks source link

Serve non dot .gophermap files as directory responses #48

Open hyperrealgopher opened 3 years ago

hyperrealgopher commented 3 years ago

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.

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

hyperrealgopher commented 3 years ago

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

sternenseemann commented 3 years ago
  1. 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.

hyperrealgopher commented 3 years ago

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_?

sternenseemann commented 3 years ago

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.

hyperrealgopher commented 3 years ago

Sounds like a great start to me!