[2.5] cannot upload media, malformed header from script 'serendipity_admin.php'

[Zugschlus]

Hi,

argl, das hatte ich jetzt in Englisch angefangen.

Nach vier Jahren Pause habe ich endlich mal wieder ein Thema gefunden über das es sich lohnen würde zu bloggen (die Telecabine Panoramic Mont-Blanc und unser vergeblicher Versuch mit ihr zu fahren). Nur, es funktioniert nicht. Ich kann keins meiner Bilder hochladen. Wenn ich auf "go" klicke, bekomme ich eine weiße Seite und diese drei Meldungen im error.log:

[Sun Aug 18 12:09:00.410996 2024] [proxy_fcgi:error] [pid 1780:tid 1809] [client 2a01:238:43fa:bc82::1f43742] malformed header from script 'serendipity_admin.php': Bad header: , referer: https://blog.zugschlus.de/serendipity_a ... =addSelect
[Sun Aug 18 12:09:00.411067 2024] [proxy_fcgi:error] [pid 1780:tid 1809] [client 2a01:238:43fa:bc82::1f43742] AH01070: Error parsing script headers, referer: https://blog.zugschlus.de/serendipity_a ... =addSelect
[Sun Aug 18 12:09:00.411075 2024] [proxy_fcgi:error] [pid 1780:tid 1809] (22)Invalid argument: [client 2a01:238:43fa:bc82::1f43742] AH01075: Error dispatching request to : , referer: https://blog.zugschlus.de/serendipity_a ... =addSelect

Das ist ein bisschen knapp als Fehlermeldung.

Da meine Installation ein wenig alt war, habe ich mal die fällige Updateorgie durchgeführt. Urzustand war php 7.4 auf Debian bullseye. Ich benutze PostgreSQL als Datenbank, und daran ist damals nach dem Erscheinen von bookworm das Upgrade schiefgegangen. Ich rollte zurück auf das alte System und ignorierte die Situation für zwei Jahre. Mein s9y war ein 2.3.5 aus dem git, und nachdem das Upgrade mit git pull / git merge eigentlich immer mit allergrößten Schmerzen verbunden war und ich eh nicht mehr das latest and greatest s9y einsetze, habe ich mich bei dieser Gelegenheit auch gleich davon verabschiedet. Folgende Schritte wurden ausgeführt:

• Update s9y von 2.3.5 auf 2.4 aus dem release.zip. Der Fehler bleibt.
• Update s9y von 2.4 auf 2.5 aus dem release.zip. Funktioniert nicht. PHP zu alt.
• zurück auf 2.4. Der Fehler ist wieder da.
• Update des Systems auf Debian bookworm (php 8.2)
• Update s9y auf 2.5, wieder aus dem release.zip. Immerhin funktioniert es diesmal ohne PostgreSQL-Fehler. Der Fehler beim Bilder-Upload ist jedoch immer noch da.

Ich bin jetzt endlich bullseye-frei, das ist schonmal ein Fortschritt.

Aber wie bekomme ich mein s9y wieder dorthin, dass ich Bilder hochladen kann?

Grüße
Marc

[onli]

Hi!
Es ist schwierig, da zu helfen, und ich habe auch direkt wenig Ideen. Ich würde angesichts der Seltenheit des Problems davon ausgehen, dass hier die Serverkonfiguration mit reinspielt.

Was mit auffällt ist `[proxy_fcgi:error]`. Ich sehe dazu uralte Fehlerbeschreibungen wie https://serverfault.com/questions/42139 ... seg-faults, die halbwegs passen könnten, wie spezifische Probleme mit dem Deflate-Modul. Oder https://bz.apache.org/bugzilla/show_bug.cgi?id=64919, eine spezifische Begrenzung in dem Modul (wobei sich da die Frage stellt, warum der Header so groß wird).

Hast du die Möglichkeit, statt proxy_fcgi das alte php_mod einzusetzen?

[Zugschlus]

Danke Dir, Dein Text hat mich wenigstens mal in die richtige Richtung gestupst. Mein Problem war natürlich eine Folge des Updates auf php 8.2, das unter Debian eine neue php.ini bedeutet, und da war das Uploadlimit noch auf 2 MB. Ich hab das jetzt hochgedreht und kann meine Bilder jetzt hochladen.

Bekommt eine PHP-Anwendung vielleicht vom PHP zurückgemeldet, dass ein Upload eins der Ressourcelimits gerissen hat? Wenn ja, wäre es fein wenn s9y das abfangen und vielleicht in eine sichtbare Fehlermeldung umformen könnte.

Grüße
Marc

[onli]

Oh. Klasse, dass dir das half, aber da war ich ja ganz in der falschen Richtung unterwegs. Ich habe bei zu großen Dateien definitiv schon passende Fehlermeldungen zumindest im Log gesehen.

Bekommt eine PHP-Anwendung vielleicht vom PHP zurückgemeldet, dass ein Upload eins der Ressourcelimits gerissen hat?

Laut https://stackoverflow.com/questions/213 ... t-max-size eventuell machbar, aber nicht so einfach wie es sein sollte, und hängt von ab wie PHPs Fehleranzeige konfiguriert ist. Also kein spaßiges Thema.

[Zugschlus]

Das sollte man trotzdem mal angehen, ohne Intuition hätten wir das heute nicht gelöst bekommen. Im Zweifel könntet Ihr ja vorgeben wie das PHP Fehlerreporting zu konfigurieren ist.