💾 Archived View for bbs.geminispace.org › u › satch › 15340 captured on 2024-05-12 at 19:23:09. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Comment by 🐐 satch

Re: "slcl 0.2.1 release"

In: s/self-hosted

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.

🐐 satch

Feb 24 · 3 months ago

19 Later Comments ↓

🐐 satch · Feb 24 at 19:22:

I get the same error when testing with Firefox, by the way.

🎵 xavi [OP] · Feb 24 at 23:10:

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.

🕹️ nerd · Feb 27 at 07:55:

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

🎵 xavi [OP] · Feb 27 at 13:17:

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

🎵 xavi [OP] · Feb 27 at 13:18:

Sorry, I meant "ignore" and not "refuse". slcl always ignores any HTTP headers that it does not know about.

🐐 satch · Feb 27 at 13:40:

@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

🐐 satch · Feb 27 at 13:42:

@xavi gitea.privatedns.org is down :( any mirrors?

🎵 xavi [OP] · Feb 27 at 20:08:

@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:

— slcl (Codeberg mirror)

🐐 satch · Feb 27 at 20:45:

Thanks! I'm getting

curl: option --fail-with-body: is unknown

When trying to use slcl-upload

🎵 xavi [OP] · Feb 29 at 09:12:

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

— curl - Release Table

🐐 satch · Feb 29 at 13:07:

Fascinating! I’m actually running curl 7.74.0 from December 9, 2020, which is the latest Debian 11 curl.

🐐 satch · Feb 29 at 13:43:

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.

🐐 satch · Feb 29 at 13:50:

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

🎵 xavi [OP] · Feb 29 at 20:28:

The "quota" key on db.json is optional: if the key is not defined, only then the quota is unlimited.

🐐 satch · Feb 29 at 20:33:

Great, thanks. Any comment on file previews?

🎵 xavi [OP] · Feb 29 at 21:46:

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.

🐐 satch · Feb 29 at 22:56:

I’m using Brave, which is chromium based.

🐐 satch · Mar 02 at 17:51:

@xavi also tried with Firefox. File previews don't work.

🎵 xavi [OP] · Mar 05 at 08:12:

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

Original Post

🌒 s/self-hosted

— u/jmjl

slcl 0.2.1 release — 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...

💬 xavi · 24 comments · 4 likes · Feb 23 · 3 months ago