$ . /etc/os-release && echo ${NAME}
Arch Linux

Sadly, no - I run an extension called “Don’t accept webp” causing that, I disabled it as soon as I saw the param to test and there’s no difference with or without the param. (webdev console request headers)

Firefox webdev console request headers (minus my personal cookie), where I’m already on the page and just click the refresh button. No if-modified-since sent to the server to trigger a proper 304 response:

GET /pictrs/image/7285a9e0-5492-4461-8188-6778d7d594c7.jpeg?format=webp HTTP/2
Host: discuss.tchncs.de
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:145.0) Gecko/20100101 Firefox/145.0
Accept: image/avif,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br, zstd
Referer: https://discuss.tchncs.de/
Sec-Fetch-Dest: image
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: same-origin
Connection: keep-alive
DNT: 1
Sec-GPC: 1
Priority: u=5, i
TE: trailers

Here’s the basic set of response headers showing the server is sending the proper cache-control directives on the image. The problem appears to be on the Firefox side using them properly.

$ curl -I https://discuss.tchncs.de/pictrs/image/7285a9e0-5492-4461-8188-6778d7d594c7.jpeg

HTTP/2 200 
server: openresty
date: Tue, 02 Dec 2025 12:51:29 GMT
content-type: image/jpeg
access-control-expose-headers: content-type, accept-ranges, transfer-encoding, date, cache-control, last-modified
vary: Origin, Access-Control-Request-Method, Access-Control-Request-Headers
cache-control: max-age=31536000
last-modified: Mon, 30 Jun 2025 11:02:52 GMT
expires: Wed, 02 Dec 2026 12:51:29 GMT
cache-control: public
access-control-allow-origin: *
x-cache-status: HIT

I assume you are just asking for clarification about the Far Side part of this, but for anyone who does not understand the It’s Always Sunny in Philadelphia part:

No, that was me too - I eventually figured out that looked like Danny DeVito’s head, made the connection it was something about that Sunny show and shrugged. I don’t watch that show so the context is/was completely lost on me, thank you for replying.

Can someone explain this to me and why it’s being upvoted in Far Side comics area?

I was taught at an impressionable age that the only winning move was not to play. Advice that has not failed me in some 42 years now. Thanks Joshua!

To share a bit more because people think it was “good”, the Battle of the Alamo was specifically because “About one hundred Texians, wanting to defy Mexican law and maintain the institution of chattel slavery in their portion of Coahuila y Tejas by seeking secession from Mexico, …” (emphasis mine) https://en.wikipedia.org/wiki/Battle_of_the_Alamo

I cannot confirm that (I have nothing to do with lemmyverse), but it was/is up and functioning so my instinct is “yes, it does not use cloudflare”.

I grabbed a quick screenshot hours ago showing the trauma; based on my recollection that I typed into the registration box of tchncs, these of the top 20 instances were all down: lemmy.world, sh.itjust.works, lemmy.dbzero.com, lemmy.zip, lemmy.ca, programming.dev, lemmy.blahaj.zone, infosec.pub, aussie.zone, readthat.com, lemmy.today. Sister sites on the piefed side (e.g. piefed.social) were also down because they’re the same admins using the same tech stacks.

A lot of lemmy instances put all their eggs in one basket and found out.

While the downtime was most active, most of the top instances were down. Lemmy.ml, feddit.org, discuss.tchncs.de and behaw.org were all up. You can use https://lemmyverse.net/ to browse things and the ones offline all show a “content error” in lemmyverse.