-- Leo's gemini proxy
-- Connecting to bbs.geminispace.org:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini; charset=utf-8
I have just released slcl v0.2.1, a bugfix release for a minimalist web file server written in C for Unix-like systems. It is strongly recommended that existing instances update to the newer version when possible.
If you have never heard about this project before, it aims to provide similar features to Nextcloud's "Files" webapp, but using ~100x less resources. It has almost no dependencies and relies on libweb, a HTTP web server library written from scratch in C.
Static Linux binaries are already available for x86, x86_64, aarch64 and armv7l.
Huge thanks to u/jmjl from tilde.green, who discovered most of the vulnerabilities that were fixed by this release.
Feb 23 · 3 months ago · 👍 lykso, norayr, jmjl, gamma
@xavi cool! I tried to set this up but got an error when running usergen:
./usergen: 22: m4: not found
I installed m4 and it's working. Maybe add that to the dependencies list?
anyway, super awesome project, thanks!
Ok but I'm getting a 502 Bad Gateway when I try to upload files :/
and the log is:
POST /upload HTTP/1.1 get_field_value: expected field:value
Hi satch, thanks for trying slcl out!
I have just added m4 to the dependencies list for Debian/Ubuntu. Thanks!
As for the 502 HTTP error, I assume this is in fact returned by the reverse proxy, as libweb (the HTTP server powering slcl) does not define this error, yet. See libweb/http.h for reference.
OTOH, the error message means that libweb found an ill-formed HTTP header: these should always follow the "key: value" format, but the expected ':' token could not be found. Uploading works out-of-the-box on Firefox and Chromium. From curl, the slcl-upload script might interest you:
Hmm.. I'm using chromium. Could it possibly be an issue with my reverse proxy configuration? I'm using the same configuration I've used with nginx previously for sites that allow uploads.
I get the same error when testing with Firefox, by the way.
I would suggest to set up slcl without a reverse proxy first - for example, by running slcl from a random port and connecting to localhost from Firefox, Chromium or curl. Then, if everything works correctly, I would check the reverse proxy configuration.
If the same error occurs, it would be interesting to see which HTTP headers are being sent to slcl, as there might be some ill-formed header that makes slcl to refuse the connection.
perhaps the reverse proxy is using an old or new version of http, such as 1.0 or 3.0 (quic/whatever)? just an empty thought...
@nerd: FYI libweb (the HTTP server library powering slcl) only supports HTTP/1.1. For example, it would complain if HTTP/1.0 is detected:
start_line: unsupported protocol HTTP/1.0
This can be reproduced easily when attempting to access a slcl instance with lynx, as it would attempt to use HTTP/1.0 by default. OTOH, HTTP/2 still sends HTTP/1.1 as its protocol name with an additional "HTTP2-Settings" header, which slcl would just refuse. This can be confirmed by running curl --http2.
Sorry, I meant "ignore" and not "refuse". slcl always ignores any HTTP headers that it does not know about.
@xavi @nerd yeah, plus we have the conf line:
proxy_http_version 1.1;
i'll try it with the cli tool, i don't have firefox or chromium on my VPS
@xavi gitea.privatedns.org is down :( any mirrors?
@satch sorry, https://gitea.privatedns.org was down for some unknown reason. Now it should be up and running.
Since this is a self-hosted Gitea instance running on a Raspberry Pi 3B, there is also a mirror on Codeberg:
Thanks! I'm getting
curl: option --fail-with-body: is unknown
When trying to use slcl-upload
@satch According to the man page for curl, --fail-with-body was added in 7.52.0. According to the official release table, 7.52.0 was released on Dec 21 2016, more than 7 years ago. Are you probably running an ancient GNU/Linux distribution on your laptop?
Fascinating! I’m actually running curl 7.74.0 from December 9, 2020, which is the latest Debian 11 curl.
I upgraded to Debian 12 (why not) and am now getting
[retrying]<!DOCTYPE html> <html> <head> <title>slcl, a simple and lightweight cloud</title> <meta charset="UTF-8"/> <link href="/style.css" rel="stylesheet"/> <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1"/> </head> <body>Maximum quota exceeded: 0 B (requested size: 39.8 KiB)</body> </html> curl: (22) The requested URL returned error: 413
I thought zero bytes was to disable the limit.
I have set a 16 GB limit and things are working now. One issue I do have is that PDFs, images, etc are not served as images but as text (when I hit the preview button).
The "quota" key on db.json is optional: if the key is not defined, only then the quota is unlimited.
Great, thanks. Any comment on file previews?
So far, I have successfully tested file previews on LibreWolf, Mull Browser, Ungoogled Chromium, Tor Browser and SeaMonkey. Some file formats, such as .wav, might or might not be previewed by the browser, and would instead be served as a regular file download.
However, I have never seen a web browser that would render images or PDFs as text. Previews only differ from regular downloads on the contents of the "Content-Disposition" HTTP header (inline or attachment; filename="<filename>", respectively), so it is up to the browser how to render "Content-Disposition: inline".
Maybe you should check your web browser settings, or try with different browsers.
I’m using Brave, which is chromium based.
@xavi also tried with Firefox. File previews don't work.
@satch I have just tested file previews on Firefox 123.0 and they work as expected. I wish I could help you with this, but unfortunately I do not know how to reproduce this issue.
Is there any unexpected output from slcl when attempting to preview a file?
-- Response ended
-- Page fetched on Sun May 19 17:00:00 2024