| Age | Commit message (Collapse) | Author |
|---|
|
This is more conforming to other CGI environments, see for example [1]
and [2].
This also allows us to easily add more fields in the future, for example
to pass the remote address, the TLS certificate, the server version, ...
[1]: https://en.wikipedia.org/wiki/Common_Gateway_Interface#Example
[2]: https://sr.ht/~int80h/gemserv/
|
|
|
|
So far, the tests are still pretty pointless, but the infrastructure to
build better tests is there now.
|
|
A static file handler that lists directory contents can be set up as
follows now:
<staticfiles path="gmdocs">
<indices />
</staticfiles>
An argument could be made to have it as an attribute instead (<...
indices="true" />), but we will have to see how this works out.
|
|
This allows Cana to do directory listings. Since we expect more settings
to become available for the static file handler (such as ExecCGI or
IndexFile), a struct holding the parameters has been introduced already.
|
|
1. This function used 'fail', which is rather bad - now it returns
'Either'
2. The function was still hardwired to the specific filenames of the
first prototypes.
|
|
This alleviates the need to define the server in Haskell and
re-compile the binary every time something in the configuration changes.
|
|
|
|
We can technically do vhosts with our current infrastructure of route
matching, but they should get some better support. Otherwise, we cannot
use things like SNI (server name indication) to send different
credentials depending on the virtual host.
The way it works now is basically that the server keeps a list of
installed vhosts, each with a domain that it matches and a loaded
certificate. Route matching in a vhost is still done the same old way,
but only routes for the matching vhost are considered in the first
place.
The API for runGeminiServer does not change, so the proper, vhost-using
API, will need a different function and API.
|
|
The culprit was using "pack" to go from the String (which we get from
readProcess) to the ByteString (which we need to have in the response).
Since "pack" just throws away all the good codepoints, we ended up with
a minor case of mojibake.
There are two possible solutions to this issue:
1) Properly encode the text from String to ByteString using
utf8-string's function
or
2) Read a ByteString from the process by using process-extras
Solution 1 works, but it has the side effect of assuming the process's
output encoding (based on the LOCALE). Furthermore, we cannot even be
sure that the script doesn't send a completely different encoding via
the charset header field. Therefore, this would introduce 2 points at
which character encoding mismatches could happen, which is not something
we're looking forward to.
Solution 2 has the benefit of just passing through the data basically
unchanged. We don't need to convert the ByteString to a textual string
ourselves, so that is a big benefit. The only thing where we now have
UTF-8 conversion is when giving the request URI to the CGI script, but
1) URIs should be ASCII & percent encoded anyway, so there's no big
chance of failure
and
2) Now we are using UTF8.fromString properly
|
|
Otherwise, the server will never get a reply and instead we'll just
silently let the client timeout :-(
This change introduces the function "uncatch", which makes an error the
inner Cana computation explicit by returning the Either directly.
With the way this is written currently, we could probably get away with
using "catch" as well, along the lines of
r geminiRequest `catch` (const $ writeResponse context ...)
|
|
|
|
|
|
Turns out that Char8.unpack is enough for our purposes, so we don't need
the utf8-string module.
|
|
|
|
|
|
Now, 'gemini://localhost' is treated the same as 'gemini://localhost/',
and will display the index instead of raising a 51.
|
|
Some simple code that allows Cana to serve files from a directory, and
not just provide static responses.
|
|
This is a working version that can serve pages, yay! A lot of features
still missing though, as well as proper package metadata.
|
