Vier Dinge, alle am laufenden Dienst gemessen.
PAPIERKORB. Loeschen war endgueltig -- bei einem Knopf "alle 3861 waehlen"
direkt neben "loeschen" ist das die falsche Haerte, und die Sicherung half nur
bis zum letzten naechtlichen Lauf. Die Datei wandert jetzt nach
/data/papierkorb, der Datensatz in eine eigene Tabelle, nach 30 Tagen raeumt
der Dienst stuendlich selbst auf. Der Ablagename traegt eine laufende Nummer:
unter demselben Pfad koennen nacheinander verschiedene Dateien gelegen haben,
und beide sollen zurueckholbar sein. Geprueft: loeschen -> oeffentlich 404,
Eintrag im Papierkorb, zurueckholen -> 200 samt neu gerechneter Vorschau.
ABRUFZAEHLER. media.abrufe und zuletzt_abgerufen. Gezaehlt wird im Speicher und
alle 30 Sekunden weggeschrieben -- ein UPDATE je Kachel waeren bei einer
Galerieseite 120 Schreibvorgaenge. Der 304 zaehlt mit (der Aufrufer WOLLTE die
Datei, er hatte sie nur schon), HEAD nicht. Was vor dem Einbau lag, steht als
"nie geholt" da, auch wenn es taeglich benutzt wurde -- die Karte im
Speicherbericht sagt das auch dazu, statt eine Zahl zu zeigen, die luegt.
WEBP OHNE ADRESSAENDERUNG. Der Pfad ist die Adresse: aus items/foo.png darf
nicht items/foo.webp werden. Die sparsame Fassung liegt deshalb DANEBEN und
wird unter DERSELBEN Adresse ausgeliefert, wenn der Aufrufer per Accept sagt,
dass er WebP versteht. Nachgemessen an einer Datei: 6448 Bytes fuer curl, 2758
fuer einen Browser. Ueber den ganzen Bestand: 3606 Fassungen, 199,3 MB ->
33,1 MB, gespart 166,2 MB. Bei 29 lohnt WebP nicht -- dort bleibt es beim
Original.
Zwei Dinge haengen daran, beide gegengeprueft: "Vary: Accept" (ohne die Zeile
legt ein Zwischenspeicher die WebP-Fassung fuer alle ab, auch fuer die, die sie
nicht lesen koennen) und getrennte ETags mit "-w" (sonst bekaeme jemand auf
seinen If-None-Match hin ein 304 fuer das falsche Bild). Gemessen: derselbe
ETag mit Accept -> 304, ohne Accept -> 200 mit dem PNG.
ZIP HOCHLADEN. Ein Archiv wird ausgepackt statt abgelegt, die Ordner darin
bleiben erhalten und haengen sich hinter den gewaehlten Zielordner. fflate und
nicht adm-zip: reines JavaScript, keine native Bibliothek -- dieses Projekt hat
schon einen halben Abend an einer ABI-Nummer verloren. Grenzen: 5000 Eintraege,
256 MB entpackt, geprueft VOR dem Entpacken (eine Zip-Bombe waere sonst schon
im Speicher). Zip-Slip gemessen: "../../../../etc/passwd" und
"..\..\windows\hosts" abgelehnt, die harmlose Datei im selben Archiv abgelegt.
UND EIN KNOPF, DER GELOGEN HAT. Der erste Nachruestlauf ueber alle Dateien
brauchte mehr als 90 Sekunden -- genau da gibt Nginx Proxy Manager auf. Der
Aufrufer sah einen 504, waehrend die Arbeit im Hintergrund weiterlief und
fertig wurde. Ein Knopf, der Erfolg als Fehler meldet, ist schlimmer als einer
ohne Rueckmeldung.
Beide Wartungsknoepfe laufen deshalb in Runden zu 300 Stueck: der Server meldet
"offen" und "fertig", die Oberflaeche ruft erneut auf und zeigt dabei "280
erzeugt, noch 129 offen ...". Gemessen: 7,8 s je Runde statt 90+ am Stueck. Der
Vorschau-Knopf hatte dieselbe Wand und wurde mitgezogen, obwohl er noch nicht
dagegengelaufen war.
Nebenbei: der Verwaisten-Sucher kennt jetzt auch /data/webp (gleiche Schleife,
Ordner im Ergebnis vorangestellt), Verschieben und Loeschen nehmen die sparsame
Fassung mit, und das Loeschen eines Ordners raeumt thumbs/ und webp/ hinterher.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Gitea legt das Wiki-Repo erst mit der ersten Seite an; Klon und Push antworten
davor mit 500, obwohl has_wiki auf true steht. Angelegt ueber die API
(POST /api/v1/repos/<besitzer>/<repo>/wiki/new) -- danach ist es ein
gewoehnliches Git-Repo und laesst sich klonen wie jedes andere.
https://git.d4rkst3r.de/D4rkst3r/d4rk_media/wiki
DIE QUELLE BLEIBT docs/ IM REPO. Ein Wiki hat keinen Zusammenhang mit dem Code:
niemand sieht, ob die Anleitung noch zu dem passt, was der Dienst tut. Unter
docs/ wandert sie im selben Commit mit der Aenderung, die sie beschreibt.
tools/wiki.ps1 traegt sie danach hinaus -- EINSEITIG, und die Wiki-Seite sagt
das auch: wer dort tippt, verliert es beim naechsten Lauf. Unschoen, aber
ehrlicher als zwei Quellen, die auseinanderlaufen.
Zwei Seiten: Home (Zuschnitt, was der Dienst kann, was zu tun ist, wenn etwas
nicht geht) und API (Endpunkte, Kopfzeilen, Fehlerantworten, Grenzen -- und die
beiden Proxy-Fallen von heute).
Nachgemessen: beide Seiten sind ohne Anmeldung lesbar (200), ein zweiter Lauf
des Skripts erkennt "bereits aktuell", und eine Aenderung kommt an.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
CODE MIT FARBE, ohne Bibliothek. Ein Hervorheber wie highlight.js wiegt mehr
als diese ganze Oberflaeche und kann fuenfzig Sprachen, von denen hier drei
vorkommen. Was Code lesbar macht, sind drei Unterscheidungen -- Kommentar,
Zeichenkette, Schluesselwort. Der Rest ist Zierde. Also ein Tokenizer in einem
Ausdruck, der seine Grenzen kennt: verschachtelte Sonderfaelle faerbt er
falsch, und bei zehn Zeilen Beispiel ist das der richtige Tausch.
DIE ANLEITUNG liegt als docs/API.md IM REPO und damit unter Versionskontrolle,
statt nur im Wiki zu stehen, wo niemand sieht, wann sie zuletzt stimmte. Sie
nennt nicht nur die Endpunkte, sondern was schiefgehen kann und wie die Antwort
dann aussieht -- samt der beiden Proxy-Fallen, die uns heute begegnet sind.
Das Gitea-Wiki gibt es noch NICHT: Gitea legt das Wiki-Repo erst an, wenn die
erste Seite ueber die Oberflaeche erstellt wird (davor antwortet der Klon mit
500). Die API-Seite verlinkt es trotzdem schon -- und sobald es existiert,
schiebt ein Befehl docs/API.md hinein.
GALERIE: die Seitengroesse ist waehlbar (30/60/120/200 statt fester 60), und
die Ordnerspalte rueckt ab 1536 px nach LINKS AUS dem Hauptbereich heraus --
15rem Spalte plus 1rem Abstand sind genau die 16rem, um die dort nach links
gezogen wird. Damit steht das Raster auf derselben Breite wie jede andere
Seite, statt um die Spaltenbreite schmaler zu sein. Darunter stapelt es wie
bisher; auf einem 1280er Schirm gaebe es keinen Rand, in den etwas ruecken
koennte.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
D4rkst3randClaude Opus 5