<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Caddy on Geeky Schmidt</title><link>https://geekyschmidt.com/tags/caddy/</link><description>Recent content in Caddy on Geeky Schmidt</description><image><title>Geeky Schmidt</title><url>https://geekyschmidt.com/images/papermod-cover.png</url><link>https://geekyschmidt.com/images/papermod-cover.png</link></image><generator>Hugo</generator><language>en</language><copyright>Copyright ©2002-2026, Nicholas Schmidt; all rights reserved.</copyright><lastBuildDate>Tue, 18 Aug 2026 13:00:00 +0200</lastBuildDate><atom:link href="https://geekyschmidt.com/tags/caddy/index.xml" rel="self" type="application/rss+xml"/><item><title>From Local Disk to SeaweedFS: Bypassing a GoToSocial Fileserver Bug with Self-Hosted S3 Storage</title><link>https://geekyschmidt.com/post/2026-08-18-seaweedfs/</link><pubDate>Tue, 18 Aug 2026 13:00:00 +0200</pubDate><guid>https://geekyschmidt.com/post/2026-08-18-seaweedfs/</guid><description>&lt;p&gt;GoToSocial had a bug serving 0-byte images. I could have patched Go source code. Instead, I bypassed the entire fileserver and offloaded 92,000 files to SeaweedFS. Sometimes the best fix is an architecture pivot, not a code change.&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="the-problem"&gt;The Problem&lt;/h2&gt;
&lt;p&gt;GoToSocial v0.22.1 has a confirmed bug where it uses &lt;code&gt;mmap&lt;/code&gt; to serve media. On certain configs, this produces &lt;code&gt;EINVAL&lt;/code&gt; errors during &lt;code&gt;close()&lt;/code&gt;, resulting in HTTP 200 responses with 0-byte bodies. Caddy logs unexpected EOF because the connection drops mid-stream. The bug doesn&amp;rsquo;t care whether the file exists — the codepath itself is broken.&lt;/p&gt;</description></item></channel></rss>