Currently Hadfield implements caps.txt through a table within it's configuration.toml. This works fine but the addition of allowing the Sysadmin to implement through an Entry instead would be a nice enhancement.

Current codebase has two major issues:

• Mix of processing on start up and when a client request comes in
• Spaghetti code, the gopher class is barely doing anything.

Having Hadfield create a default configuration file and sample structure in the default location would allow new users to test out the application quickier and give a more hands-on example of how Hadfield works.

Problem

When a Directory Type Entry has a Target that doesn't match the Selector, the server crashes due to something being undefined.

hadfield_1  | User configuration loaded from: /app/data/configuration.toml
hadfield_1  | Server listening on gopher://0.0.0.0:70/
hadfield_1  | Incoming message:  
hadfield_1  | Incoming message:  /hole
hadfield_1  | /app/source/catalogue.js:79
hadfield_1  |                           const message = this.menuList[selection.target].sort((scooby, shaggy) => {
hadfield_1  |                                                                           ^
hadfield_1  | 
hadfield_1  | TypeError: Cannot read properties of undefined (reading 'sort')
hadfield_1  |     at Catalogue.query (/app/source/catalogue.js:79:53)
hadfield_1  |     at Gopher.serve (/app/source/gopher.js:54:30)
hadfield_1  |     at SocketManager.emit (node:events:390:28)
hadfield_1  |     at Socket.<anonymous> (/app/source/server.js:20:10)
hadfield_1  |     at Object.onceWrapper (node:events:510:26)
hadfield_1  |     at Socket.emit (node:events:390:28)
hadfield_1  |     at addChunk (node:internal/streams/readable:315:12)
hadfield_1  |     at readableAddChunk (node:internal/streams/readable:289:9)
hadfield_1  |     at Socket.Readable.push (node:internal/streams/readable:228:10)
hadfield_1  |     at TCP.onStreamRead (node:internal/stream_base_commons:199:23)

Problem

Host and Port information is currently being handled by the Menu class, additionally the Host and Port information is kept in a master configuration file meaning no other servers can be listed in a Menu

Problem

Trying to create a menu entry that links to an ancestor directory causes Hadfield to get stuck in an infinite loop of parsing.

Problem

When an active Hadfield server gets a connection from an nmap port scan, the server fatally crashes with an unhandled error:

node:events:368
      throw er; // Unhandled 'error' event
      ^

Error: read ECONNRESET
    at TCP.onStreamRead (node:internal/stream_base_commons:220:20)
Emitted 'error' event on Socket instance at:
    at emitErrorNT (node:internal/streams/destroy:157:8)
    at emitErrorCloseNT (node:internal/streams/destroy:122:3)
    at processTicksAndRejections (node:internal/process/task_queues:83:21) {
  errno: -104,
  code: 'ECONNRESET',
  syscall: 'read'
}

Nmap reports the port in use by Hadfield to be of service afs3-fileserver

Steps to Reproduce

1. Start a Hadfield server instance
2. Run nmap -p{PORT} localhost
3. Crash

Problem
Currently Hadfield takes in a single value server.host and uses it for both the server bindHost and the gopher displayHost. This causes issues when the application is being run behind a reverse proxy or in a container.

Solution
Create addition configuration option gopher.host, when this configuration option is set, use it instead of server.host as the gopher displayHost.

caps.txt has the properties ServerSoftware and ServerSoftwareVersion, having Hadfield autopopulate them when the caps.txt functionality is enabled sounds like a good idea.