feat: Papierkorb, Abrufzaehler, WebP ohne Adressaenderung, ZIP hochladen
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>
This commit is contained in:
+46
@@ -37,6 +37,52 @@ und niemand merkte es, bis das Bild fehlt.
|
||||
> Ein führender Unterstrich fällt durch. Das ist kein erfundener Fall: das
|
||||
> Fotostudio legt seine Leerbilder als `_plate` ab.
|
||||
|
||||
### Groß- und Kleinschreibung
|
||||
|
||||
Was über das Dashboard oder ein Werkzeug hochgeladen wird, kommt **klein**
|
||||
an: `WEAPON_SMG.png` liegt als `weapon_smg.png`. Der Grund ist, dass ein Name
|
||||
zu einer Adresse wird und Adressen sich nicht auf die Schreibweise eines
|
||||
Dateisystems verlassen sollen.
|
||||
|
||||
Für ein Skript heißt das: **die Vorlage arbeitet mit Kleinbuchstaben.**
|
||||
|
||||
```lua
|
||||
local url = ('https://fivemanage.d4rkst3r.de/f/items/%s.png'):format(item:lower())
|
||||
```
|
||||
|
||||
Über `/api/upload` mit eigenem `X-Path` gilt das nicht — dort steht der Pfad
|
||||
so, wie er geschickt wird.
|
||||
|
||||
---
|
||||
|
||||
## Dieselbe Adresse, zwei Fassungen
|
||||
|
||||
Neben jedem PNG und JPEG kann eine **WebP-Fassung** liegen. Ausgeliefert wird
|
||||
sie unter **derselben Adresse** — welche der beiden kommt, entscheidet die
|
||||
Kopfzeile `Accept` des Aufrufers:
|
||||
|
||||
```
|
||||
Accept: …image/webp… → Content-Type: image/webp (klein)
|
||||
kein Accept → Content-Type: image/png (das Original)
|
||||
```
|
||||
|
||||
Nachgemessen an `probe/probe-webp.png`: 6448 Bytes für `curl`, 2758 Bytes für
|
||||
einen Browser. **Für ein Skript ändert sich nichts** — Lua schickt kein
|
||||
`Accept: image/webp` und bekommt weiterhin Byte für Byte das Original.
|
||||
|
||||
Zwei Dinge, die daran hängen:
|
||||
|
||||
- Die Antwort trägt `Vary: Accept`. Ohne die Zeile legte ein Zwischenspeicher
|
||||
die WebP-Fassung für alle ab, auch für die, die sie nicht lesen können.
|
||||
- Die beiden Fassungen haben **verschiedene ETags** (die WebP-Fassung endet auf
|
||||
`-w`). Sonst bekäme jemand auf seinen `If-None-Match` hin ein 304 für das
|
||||
falsche Bild.
|
||||
|
||||
Erzeugt werden die Fassungen beim Hochladen; für alles, was vorher schon da
|
||||
war, gibt es im Dashboard unter **Speicher → Wartung** den Knopf
|
||||
„Sparsame Fassungen erzeugen". Wo WebP nicht kleiner ausfällt, entsteht keine —
|
||||
dann bleibt es beim Original.
|
||||
|
||||
---
|
||||
|
||||
## Anmeldung: Token
|
||||
|
||||
Reference in New Issue
Block a user