Oto Šťáva

Newlines in bad places

Mon, 09 Mar 2026 00:00:00 +0000

So it turns out that if you violate standards, bad things happen. Who woulda thought?

For the longest time, I’ve had this little problem with my web server, in that some clients would refuse to load it. The major ones worked – Firefox, Chromium, cURL, Android apps – all of them good. The first time I encountered this problem was when I was working on hardening the web server’s security (TLS, CSP, that kind thing). I would test the site with Mozilla Observatory, only for it to fail with a vague error message that the site couldn’t be loaded.

Since everything else worked, I didn’t put too much thought to it back then. Maybe there was some weird issue that maybe the Observatory had Scaleway—my current VPS host—banned for some reason? I left it at that for some time.

Observatory showing a vague error

But then, the issue kept turning up in other places. I’ve been setting up OpenGraph for the website, testing it with various tools. Some would work well, but others would fail. Again, with no helpful messages, everything along the lines of “something went wrong” or “is the site down?”. No, it isn’t! I’m looking at it in my browser, dammit! Mastodon would seemingly ignore my OpenGraph tags, while other services happily showed pretty links. I kept debugging, to no avail. SslLabs worked fine. Nginx’s debug log turned up nothing useful – clients would do the proper TLS handshake, receive the HTTP headers, then close the connection. I couldn’t, for the life of me, figure it out. So I gave up for several more months. My actual use cases weren’t hindered, so I just couldn’t be bothered.

Fast-forward to today. Out of curiosity, I tried to open my website in a nightly build of Servo. It, like other random clients, would refuse to load up the site:

Servo could not load the requested page: client error (SendRequest)

As with all the other offenders, not a very helpful message. I tried searching for the message. Turns out the format is common for various Rust projects using the reqwest crate, among them Deno, a JavaScript runtime. I found an issue on Deno’s GitHub about a similar, but ultimately unrelated problem – something about a proxy, not interesting to me. But I got curious. I took the reporter’s script, removed the proxy option and swapped the URL to my website:

using client = Deno.createHttpClient({});
await fetch("https://spiffyk.cz", { client });

I ran it with Deno and… bingo!

error: Uncaught (in promise) TypeError: error sending request from *snip* for https://spiffyk.cz/ (*snip*):
       client error (SendRequest): invalid HTTP header parsed

I started digging through my Nginx configs, then I found it:

add_header "Content-Security-Policy"
    "default-src 'self';
    object-src 'none';" always;

In an attempt (a bad one at that, now that I’m looking at it) to make the config more readable, I’ve split the CSP directives onto multiple lines. Since neither Nginx nor my web browsers ever complained (not even in devtools), I never gave it much more thought and assumed Nginx would replace the newline with a space. It wouldn’t. It just pasted that newline right into the HTTP response. Many clients, adhering to the infamous “Postel’s law¹,” just swallowed that right up. Others—rightfully, in my opinion—refused. Turns out violating RFCs just doesn’t pay off.

Well, easy fix. I merged the directives onto a single line, and one systemctl reload nginx later, everything works! So I can finally be proud of my A+ score in Observatory, and show you our cat every time I share a link to my blog:

A rich link on Mastodon leading to my website, accompanied by a photo of our cat

So we made a game

Mon, 15 Dec 2025 00:00:00 +0000

A screenshot of Fruits & Tails

After a year of on-and-off work, one of my long-term dreams has come true; that is, to create—and actually finish—a project together with Zuzka, my beloved partner in crime. What we created is in terms of mechanics a tiny game, a sort of remix of four-in-a-row, but with cute squirrels, flashy animations, a nice tutorial, and the grid is hexagonal instead of square. As expected, I was responsible for the coding, while Zuzka designed all of the UX/UI, as well as all of the super cute hand-drawn art.

Our game is called Fruits & Tails and you can play it right now on your PC, phone, tablet, or whatever device with a modern-enough web browser you have on hand, at FruitsAndTails.fghj.cz.

Fruits & Tails is completely hand-made. It was written in Zig, with its only external dependencies being the standard library, Web APIs (mostly CanvasRenderingContext2D and input events), and UglifyJS – the last one being optional to make release builds as small as possible. We’re not even using any ready-made glue code of the WASI or Emscripten kind – the glue to interact with the Web APIs is just a 600-line index.js file, hand-rolled on an as-needed basis. All this makes for a neat package of 5.1 MiB (compiled in ReleaseSmall mode, with JavaScript minification), of which 4.8 MiB are the art assets.

Currently, you can play this with a friend, offline, on a single device. The plan, though, is to also add a way to play online, and I’ve already been cooking up an algorithmic opponent (you know, AI, but the good kind) that is already quite competent at playing the game, so that’s coming in an update soon-ish.

If you want to know more about our little journey, stay tuned! I’m going to touch on the brief history of the game, as well as some of the inner workings of its engine. I’m also planning to release the source code, so if you are looking into Zig—specifically in conjunction with WebAssembly—it might just turn out to be a helpful resource.

You can subscribe to this blog’s RSS feed or follow me on Mastodon to stay up to date!

Diffing Word and Writer documents with Git

Fri, 12 Sep 2025 00:00:00 +0000

TL;DR: Skip my blabbing and go directly to the configuration

Diff of a DOCX file with a review comment in Forgejo

At my day job, we have recently been evaluating Forgejo—obviously primarily for hosting of our software sources with Git—but we have also been pondering other possible use-cases. Since the company is pretty small, we want to keep the number of tools we use rather low, so as to keep the system-administrative workload at a minimum.

One such pondered use-case for Forgejo is the review of non-technical legal and policy documents. These are generally created with Microsoft Word (docx) and/or LibreOffice Writer (odt), from templates, complete with the company’s standardized visual identity. To emphasize, the goal of this endeavour cannot be that my non-technical colleagues will magically switch from Word to Markdown, reStructuredText, or LaTeX. That may be my perfectionist-programmer-ass pipe dream, but we live in the real world.

So the question is this: can we get Git and Forgejo to show meaningful differences between two versions of a Word/Writer document? Spoiler: the answer is of course yes, but first, let’s look at what failed (or you can always go TL;DR).

What does not work

At this point I think it is pretty common knowledge amongst the tech-savvy crowd that both docx and odt are “just” specifically structured ZIP archives containing a bunch of XML files and assets (like images) that comprise the document. My initial idea then was very simple – could we get Word and Writer to open and edit documents unpacked? That way, we could simply keep the whole structure in a Git repository, making diffing and even merging pretty easy, since XML is a text-based format.

Unfortunately, Writer only supports working with properly packaged documents and a cursory internet search indicated that Word is the same in this regard. I have checked with LibreOffice both in the GUI, which offers no way of opening entire directories, as well as trying to make it run with the terminal. Simply running libreoffice . in a directory containing an unpacked document results in LibreOffice not even starting – it shows the splash screen, then exits with code 0 as if everything was cool and dandy.

While I was at it, I also took a look at an ODT’s XML files in a text editor. I really should not be surprised, but apart from the nicely formatted manifest.rdf, all of the other XML documents are simply dumped on a single line. This would make diffing quite the nightmare. Even if I did some automated reformatting, the OOXML format used by Office would still be quite unreadable due to historical cruft. Not to mention that I probably cannot expect non-techies to dig through XML syntax while reviewing document changes.

Again, none of this is particularly surprising. The files are not really meant to be perused by humans. But it further drives the point home that this approach is not really feasible.

Pandoc to the rescue

So, as a surprise to virtually no-one, Git is really powerful. One source of this power is that you can hook arbitrary programs to many parts of its mechanism, modifying the outcome. Today, we are going to be using the diff drivers, to hook programs to the diffing mechanism in Git. Diff drivers can be declared by adding [diff "driver-name"] sections in your Git configuration, allowing us to change git diff’s behaviour quite substantially – we can even completely substitute the diffing program this way. What we are currently interested in the most, though, is the textconv property.

In simple terms, textconv allows Git to call upon an arbitrary program to do a one-way conversion from an arbitrary file format to a preferably plain-text representation. Emphasis on one-way, because this is really only useful for reviewing diffs. You cannot use this to patch files.

How to actually configure this

First, make sure you have pandoc installed. It is available in most of the major Linux distributions’ repositories, so just call upon your apt, pacman, or whatever floats your distro’s boat.

Update (2025-09-12): Shortly after publishing the post it was brought to my attention that pandoc may access external files when run on certain types of untrusted inputs. Based on my understanding of Pandoc’s official note on security this should not be a problem for odt/docx inputs and Markdown outputs, but other combinations might be risky. It is recommended—especially when dealing with untrusted files—to use the --sandbox option when calling Pandoc like this. The examples in this post were amended to include the --sandbox option to be on the safe side.

Git

Once pandoc is installed, define this diff driver in your Git configuration:

[diff "pandoc"]
	textconv = pandoc --sandbox --to=markdown

Finally, to actually use the driver, you also need to configure Git attributes for odt and docx files. You may do that either globally in your ~/.config/git/attributes file, or in a .gitattributes file inside of your repositories:

*.odt diff=pandoc
*.docx diff=pandoc

Note that pandoc only supports the newer docx format and not doc. Hopefully nobody is using that old thing anymore, but just so you know.

Forgejo

If you want to do this same transformation in Forgejo’s diffs, you may put this [git.config] section in your app.ini:

[git.config]
core.attributesFile = /path/to/git/attributes
diff.pandoc.textconv = pandoc --sandbox --to=markdown

Bonus round: Document previews in Forgejo

Additionally, you can use pandoc to preview documents (when not diffing) in Forgejo without downloading them in a very similar fashion. Mind you it will not be perfect – only properly semantically formatted text will work well, the document will not be split into pages, and you won’t see any images embedded in the document. But for basic previews to make sure you are looking at the right document, or to quickly check some facts in said document, I think this is pretty neat.

To do this, you can use the [markup.*] section in the app.ini file:

[markup.docx]
ENABLED = true
NEED_POSTPROCESS = false
FILE_EXTENSIONS = .docx
RENDER_COMMAND = pandoc --sandbox --from=docx --to=html

[markup.odt]
ENABLED = true
NEED_POSTPROCESS = false
FILE_EXTENSIONS = .odt
RENDER_COMMAND = pandoc --sandbox --from=odt --to=html

The main difference here is that Forgejo (as opposed to Git) does not provide the file name to Pandoc. It instead provides the file contents on the standard input, meaning that Pandoc cannot determine the file type from the name. To remedy this, we need to specify the --from= argument to let Pandoc know what the source file format is. We are also converting directly to HTML instead of Markdown, because we don’t need the extra step – Forgejo would need to convert from Markdown to HTML to display the file to the user anyway.