Komm in meinem Dickdarm!

>>81798
Habe bisher noch von keinem solchen Problem auf Schlaufonen gehört. Ich habe allerdings mal in die Logs geschaut und da sind tatsächlich ein paar 400er-Anfragen bei deiner IP. Auffällig ist, dass das alles HTTP-1.1-Anfragen sind, während die HTTP-2.0-Anfragen von der gleichen IP funktionieren. Bei den HTTP-1.1-Anfragen scheint außerdem der Benutzeragent zu fehlen, was darauf schließen lässt, dass dein Brausierer da ziemlichen Murks sendet. Ich denke eher nicht, dass das ein Fehler in der Brettweichware ist, weil die sich um sowas eigentlich gar nicht kümmert - die Brettweichware liefert nur den unkomprimierten, unverschlüsselten Inhalt an nginx, und der liefert es dann aus und kümmert sich die verschiedenen HTTP-Versionen. Es würde mich sehr wundern, wenn nginx da einen Fehler hätte. Wahrscheinlich liegt es eher an deinem komischen Brausierer.

>Jemand ne Ahnung wie man sowas auf Schlaufon anständig debuggen kann?
Nicht direkt. Sofern entsprechende Expertise und Lust vorhanden ist, könntest du dietchan lokal bei dir unter gdb laufen lassen und einen Breakpoint z.B. auf read_data [0] setzen und dann mal schauen, was der Brausierer da eigentlich sendet und wo es knallt. So habe ich schon den einen oder anderen Fehler gefunden.

[0] https://gitgud.io/zuse/dietchan/-/blob/master/src/dietchan/src/dietchan.c#L178

Käferberichte Schlaufon:

- Direktes Ansteuern von /fefe/ geht nicht. Trotz mehrmaligen Versuchen immer nur "Bad Request". Was funktioniert, ist der Aufruf von /, wobei der erste Aufruf immer ein "Bad Request" ist. Nach einer Neuladierung taucht das Brett dann doch auf und auch /fefe/ kann angesteuert werden.
- Bild-Downloads funktionieren nicht. Es scheint erst etwas geladen zu werden, dann "Download unsuccessful. <Untitled>". Passiert sowohl per Klick auf Dateinamen als auch "Speichern unter" auf das geöffnete Bild.

Jemand ne Ahnung wie man sowas auf Schlaufon anständig debuggen kann?

Gesendet von meinem Shitphone5m (Android 8, Firefox Klar/Focus, org.mozilla.klar)

Stoss.

Stoss.

Stoss.

Teststoss.

Ist wieder da. Kann man nichts machen.

Ein weiterer Test

Nacht drüber geschlafen. Ein

funktioniert. Schuld ist also wieder das ewige CSS.

Mit white-space: pre; würden Leerzeichen erhalten bleiben, aber Zeilen nicht umbrechen.
Mit white-space: pre-wrap; würden Leerzeichen erhalten bleiben, und Zeilen umbrechen.

Zuse: Wenn nichts dagegen spricht, wäre es möglich im CSS für .code ein white-space: pre-wrap; hinzuzufügen?

>>79422
Die einzige Stelle, wo Dietchan ein Leerzeichen "verschluckt", ist vor Zitaten. Ist nebenbei eine gute Möglichkeit, um Schlaufonpfostierer zu entlarven, weil einige Schlaufonbetriebssysteme wohl automatisch ein Leerzeichen nach >> einfügen.


>Wildschwein
>>79422


>Wildschwein
>> 79422

Erkennen und vermeiden!

>>79412
Korrektur: Doppelleerzeichenerkennung war eine idiotische Hypothese von mir, Dietchan schreibt keine Pfosten um; hat eher etwas mit dem <code>-HTML-Tag zu tun.

asd asd text
1 1 text
2 2 text

Ist da die Doppelleerzeichenerkennung zu aggressiv?