↑

Diskussion 🤯
Bilder nicht versehentlich als Text laden

Wenn man zum Beispiel mit [a]-> ein Bild statt wie vorgesehen eine Aneamaldatei lädt, kann die unsinnige Ausgabe den Browser überfordern (gemeldet von David). Muss man diese Art der Fehlbedienung durch den Autor verhindern? Und kann man, ohne auch berechtigte Fälle zu beschneiden?

  1. Bei [a]-> erscheint die Bedingung möglich, dass die Dateiendung .nml sein muss, um so etwas zu verhindern. Bei [t-…]-> allerdings ist eine Positivliste von Dateiendungen sehr einschränkend. Wäre eine Negativliste von Dateiendungen denkbar? Dabei ist zu beachten, dass man mit Zeileneinschränkung wie [t]->testbild.png?1 durchaus sinnvolle Ausgaben auch bei Bildern erzeugen kann.

  2. Man könnte die Möglichkeit einräumen, in aneamal-config.php die Dateiendungen für verschiedene Datei-Tags einzuschränken. Alternative: standardmäßige Einschränkung, welche in aneamal-config.php aufgehoben werden kann.

  3. Falls Einschränkungen standardmäßig gesetzt werden, welche Endungen sollen dann gültig sein für die Fälle, in denen Textdateien im weiteren Sinn geladen werden:

    [a] [a-…]
    [b] [p]
    [d] [q]
    [h]
    [t]
    [t-…]
    @style
    @script

    Der Vollständigkeit halber könnte man auch für die anderen Datei-Tags Beschränkungsmöglichkeiten setzen. Ich neige allerdings dazu, möglichst wenig an Beschränkungen zu setzen. Nicht vergessen sollte man, dass es hierbei nur ums sanftere Abfangen versehentlicher Falschangaben seitens des Autors geht und nicht um eine Funktion, die im wunschgemäßen Betrieb einen Vorteil bringen würde.

  4. Zur Frage in @2, ob

    A. standardmäßige Einschränkung, die in aneamal-config.php aufgehoben werden kann, oder
    B. standardmäßig keine Einschränkung, die in aneamal-config.php aber hinzugefügt werden kann

    denke ich, dass nur eine standardmäßige Einschränkung (A) das gemeldete Problem lösen würde. Im Fall von (B) würde man sich ja frühestens auf die Suche nach der Konfigurationsmöglichkeit machen, wenn man schon ins Fettnäpfchen getreten ist.

  5. Zu @3: Ich denke, dass mindestens folgende Dateiendungen in Groß- und Kleinschreibung möglich sein müssen:

    [a] [a-…]: .nml
    [b] [p]: .tsv
    [d] [q]: .tsv, .nml
    [h]: .html, .htm, .svg, .xhtml, .xml, .mml (für MathML)
    [t]: mindestens alle sonst genannten + .txt
    [t-…]: mindestens alle sonst genannten + .txt
    @style: .css
    @script: .js

  6. Aus historischen Gründen könnte zu .nml jeweils .aneamal hinzugefügt werden. Bei [t]-> und [t-…]-> ist eigentlich jede Endung sinnvoll, die irgendein Textformat enthält. So habe ich auf dieser Internetpräsenz bereits Python-, PHP- und QBasic-Quelltexte angezeigt, die typischerweise Endungen wie .py, .php, .bas haben. Gerade bei Sprachen wie Python und PHP (und Ruby und Perl und …) die auch auf dem Server ausgeführt werden können und die zu diesem Zweck sowieso auf dem Server liegen, muss man mit solchen Endungen rechnen. Eine alte QBasic-Datei könnte man natürlich problemlos in .txt umbenennen, wenn nur der Quelltext gezeigt werden soll, ohne dass damit etwas passiert.

  7. Ein alternativer Ansatz, der zumindest die größten Fehler vermeiden würde, wäre nicht die Dateiendungen zu beschränken, sondern die Dateigröße. Textdateien, die in einen Webseite eingebunden werden sollen, werden zum Beispiel kaum 1 Megabyte überschreiten, wohingegen das bei Videos und Bildern und Audiodateien leicht passieren kann. Vielleicht genügt auch ein Viertel davon schon als Grenze, 250 kByte also. Knapp über 130 kByte dürfte die größte auf dieser Internetpräsenz hereingeladene Datei betragen (https://prlbr.de/projekt/aneamal/quelltext/html).

    Freilich könnten Nutzer bei Bedarf die Grenze per aneamal-config.php beliebig erhöhen.

  8. Wenn du Bock auf schlaflose Nächte hast, kannst du ja die Ebene Error, die es heute schon gibt und auf der Seite Fehlermeldungen erzeugt, von der Ebene Tipps unterscheiden. Bei Ungereimtheiten würde dann im Ordner wo das Merkwürdige auftritt eine *.txt kreiert die Tipps enthält, zB dass auf [j,i] eine Bildfatri folgen sollte. Das wäre aber nur intern ersichtlich

  9. @8, so eine Tipp-Funktion wäre vielleicht etwas, was sich mit einer Update-Info wie im letzten Absatz von Kommentar 3 auf der Seite https://prlbr.de/projekt/aneamal/diskussion/update-funktion#K3 beschrieben, kombinieren ließe.

  10. @8: Ich habe die Idee in https://prlbr.de/projekt/aneamal/diskussion/autokorrektur-statt-fehlermeldung#K2 aufgegriffen. Dass ein versehentliches Laden einer großen Mediendatei mit dem falschen Datei-Tag wie [a]-> oder [t]-> eine Ausgabe erzuegen kann, die den Browser überfordert, wäre damit aber noch nicht gelöst. So lohnt es, die Möglichkeiten einer Dateigrößenbeschränkung oder einer anderen Lösung im Auge zu behalten.

  11. Ich gedenke die Dateigröße von Textdateien wie in @7 beschrieben auf ein vernünftiges Maß zu beschränken. Bei Bedarf kann sie jederzeit angehoben werden, allerdings nicht per aneamal-config.php, sondern per Metadeklaration à la @text-file-size. Der genaue Name ist noch festzulegen. Die Einstellung per Metadeklaration hat den Vorteil, dass es lokal dort gemacht werden kann, wo man es braucht, und nicht für die komplette Internetpräsenz geschehen muss.

  12. Im Testbetrieb funktioniert die Größenbeschränkung bei Textdateien im weiteren Sinne nun. Die Grenze kann von 128 kByte per Metadeklaration mit @textlimit angehoben werden. Der Wert sowie der Metadaten-Name können sich bis zur Veröffentlichung noch ändern.

  13. Statt @textlimit habe ich mich für @textcap und derzeit 256 KiB als Standardwert entschieden.

    Von den in @3 genannten Verweisen auf zu ladende Textdateien im weiteren Sinne sind übrigens @script und @style nicht beschränkt. Die Verwechslung mit einem Bild ist bei diesen einerseits nicht naheliegend. Andererseits würde, da es sich bei ihnen genau wie auch bei der Größenbeschränkung um Metadeklarationen handelt, ggf. die Verarbeitung komplexer: Es stellte sich die Frage nach der Verarbeitungsreihenfolge der Metadaten. Würde etwa beim Laden der Datei style.css in folgenden Beispielen die gleiche Größenbeschränkung gelten oder wären es unterschiedliche?

    --- Beispiel 1 ---

    @textcap: 123
    @style: ->style.css

    --- Beispiel 2 ---

    @style: ->style.css
    @textcap: 123

  14. Ich schließe die Diskussion, da @textcap das Problem mildert.
    Verhindern kann man Fehleingaben nicht.