sternenseemann / spacecookie Goto Github PK
View Code? Open in Web Editor NEWgopher library & server written in Haskell
Home Page: https://sternenseemann.github.io/spacecookie/
License: GNU General Public License v3.0
gopher library & server written in Haskell
Home Page: https://sternenseemann.github.io/spacecookie/
License: GNU General Public License v3.0
Add systemd support for the server executable (socket activation and notify service type).
Work in Progress, see the systemd-support branch
Current Progress:
systemd
haskell packagespacecookie
does not have to depend on network
.service
files.This is the new feature I am planning for 0.2.1.0.
We have a map like this:
M.Map FilePath GopherFileType
The configuration option could look like this, allowing to override the mapping:
{
"file-types": {
"apng": "I"
}
}
Also the default fallback should be configurable (currently File
).
spacecookie > /tmp/stack-e91b7c5fd4ba17cb/spacecookie-1.0.0.0/server/Network/Spacecookie/Config.hs:28:28: error:
spacecookie > • Couldn't match expected type ‘Key’ with actual type ‘Text’
spacecookie > • In the second argument of ‘(.:?)’, namely ‘x’
spacecookie > In the expression: v .:? x
spacecookie > In an equation for ‘maybePath’: maybePath [x] v = v .:? x
spacecookie > |
spacecookie > 28 | maybePath [x] v = v .:? x
spacecookie > | ^
spacecookie >
spacecookie > /tmp/stack-e91b7c5fd4ba17cb/spacecookie-1.0.0.0/server/Network/Spacecookie/Config.hs:29:28: error:
spacecookie > • Couldn't match expected type ‘Key’ with actual type ‘Text’
spacecookie > • In the second argument of ‘(.:?)’, namely ‘x’
spacecookie > In the first argument of ‘(>>=)’, namely ‘v .:? x’
spacecookie > In the expression: v .:? x >>= fmap join . traverse (maybePath xs)
spacecookie > |
spacecookie > 29 | maybePath (x:xs) v = v .:? x >>= fmap join . traverse (maybePath xs)
spacecookie > | ^
Would be mostly just to have it or as a gimmick.
Probably best option is to add manpages:
spacecookie(1)
Usage, Configuration, License, …spacecookie.json(5)
spacecookie-gophermap(5)
README.md
To reproduce curl -vv -s -f
an gopher url for spacecookie a few times, eventually you will have curl failing with 56 similar to this:
…
The file type characters are defined in [RFC1436](https://tools.ietf.org/html/rfc1436#page-10).
* Recv failure: Connection reset by peer
* Closing connection 0
Detailed documentation on the gophermap format [can be found here](./docs/gophermap-pygo⏎
BSD support would be nice, socket
depends on GNU/Linux Socket API though.
We always use the binary file response which we should probably resolve to call ourselves a RFC1436 implementor although binary file responses work well enough.
Currently all exceptions except IOExceptions are kind of ignored. This should be fixed and handled properly™. Probably removing MonadError
altogether would do the trick.
Most notably it is not possible to handle SocketExceptions
with MonadError
.
Optional CGI support could be interesting. Could starting point could be looking at how geomyidae (gopher://bitreich.org/1/scm/geomyidae/) passes info to CGI scripts. Also should check how/whether other server implementations do CGI.
On my server I have two different gopherholes I want to expose to the world. Currently they run on different ports. I'd like to be able to configure spacecookie to act as a reverse proxy to sort incoming gopher requests to a configured gopherhole. For example, a simple configuration could be detecting the base directory of "forum/" in the selector and forwarding selector to a configured gopherhole and sending its response back.
I suppose all I really want is the ability to have spacecookie map certain base directories to certain gopherholes, and everything can be communicated via a consistent port.
Would you like me to work on a PR for this concept? Would you like to implement?
I'm posting using my phone and sorry if my English is poor.
^Cspacecookie: ExitFailure 1
spacecookie: awaitEvent: invalid argument (Bad file descriptor)
Probably have to check the source since the documentation is ambiguous. This should best be addressed in 0.3.0.0 to avoid consecutive breaking changes to gophermaps.
Seems like we need to introduce an dependency on async
for #42, so converting the other threading stuff to async
could be interesting.
This behavior can already be achieved when using a systemd based setup, but we should probably support it also in a systemd-less scenario. Binding to a specified address could be how to solve it, but link local is the most important in case you want to proxy spacecookie somehow or point a TOR hidden service to it without leaking the gopher space on the regular address.
selector
The selector is the name of the file on the server. If it
begins with a slash, it is an absolute path; otherwise, it is
interpreted relative to the directory that the gophermap file is
in. If no selector is specified, the description is also used
as the selector.
spacecookie currently interprets relative selectors wrong.
Recently it seems to be a trend to TLS-enable gopher servers and even some gopher clients seem to support TLS. I don't think it's a good idea to support it in spacecookie, since it is a non-standard feature, but it seems like a good idea to figure out, how TLS typically is set up for gopher and provide an stunnel
(?) based example configuration for TLS with spacecookie.
The best way to set up an encrypted spacecookie remains to use a hidden service (but we should close #13 for that).
A lot of the times a error occurs, the default exception is thrown.
The bad thing currently is that the configuration has to match in two places: a) the spacecookie.socket
file and b) the spacecookie.json
config. This can be improved by:
Useful for Tor Onion Services.
The current log system is alright, but doesn't allow the user to log anything. I'm also kind of unhappy that we always have a TimeFastLogger
although it may not be used (glcTimed = False
).
I think a good way forward is to rework logging again completely and let the user set an IO
action for logging. Additionally I think the LogMessage
sum type needs to be simplified somehow, without sacrificing the ability to hide private data.
This should be done before 0.3.0.0
since I don't want to break the API twice in a row.
JSON is not a configuration file format. I'll keep supporting it in the future, since it is convenient for the NixOS module.
As we keep JSON, we should maybe look into something aeson
based, maybe YAML? Otherwies toml or ini seems fine.
Would break library interface unfortunately, but having something like
data GopherRequest
= GopherRequest
{ grSelector :: ByteString
, grAddress :: (Word16, Word16, Word16, Word16, Word16, Word16, Word16, Word16) -- ipv6 address
}
Could be very useful for applications which want to kind of differentiate different users.
Really a shame that there is no self hosted page for spacecookie yet. Shouldn't be too hard to set up with existing NixOS infrastructure and my tries towards generating project pages.
Feature request.
It would be great if I could arbitrarily launch spacecookie
when I build random gopherholes as a test and I just want to see what the product looks like after I build it, without having to create a config file to test locally.
I want to, for testing purposes, be able to use spacecookie
without specifying a config file.
I keep forgetting to do this.
Also: deal with empty lines (related)
I was poking through your code and noticed the filetypeMap
.
Would you like a more thorough utility for such? I have a half-baked, but functional utility filesig which provides a mapping for a ton of files based off of file signatures (and I think even file extensions? although hit's been a while). I can update this library if you are interested in it.
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 believe network
should now offer everything we need and socket
has become unmaintained, dropping out of Stackage Nightly recently.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.