media/{filename}/update (PUT/PATCH): Multipart-File-Upload schlägt bei aktivem enable_post_data_reading fehl
まだ誰も着手していません。
評価
調査の方向性
まず、PHP enable_post_data_reading=On の環境で handleUpdateMedia()、parseMultipartInput()、および media/{filename}/update route を追跡し、multipart PATCH または PUT で空の php://input を再現します。ネイティブな POST 処理、method override の動作、および提案されている POST-route の代替案を比較します。完了条件は、multipart update によってメタデータだけが更新されるのではなく、media file が確実に置き換えられ、response が実際の結果を反映することです。
索引モデルが issue の本文から書いたものです。
説明
Problem
handleUpdateMedia() erwartet bei multipart/form-data-Requests, dass parseMultipartInput() den Body manuell aus php://input parsen kann, weil PHP $_FILES nur bei POST automatisch befüllt (Kommentar im Code: "PUT/PATCH füllt $_FILES nicht").
Das stimmt nur zur Hälfte: Ist enable_post_data_reading aktiv (php.ini-Default, On), liest PHP den kompletten multipart/form-data-Body bereits vor jedem Nutzcode aus php://input, um ihn (nur bei POST) in $_FILES zu befüllen. Bei PUT/PATCH wird der Body dabei trotzdem vollständig konsumiert und verworfen, ohne $_FILES zu befüllen. Für parseMultipartInput() bleibt dann buchstäblich nichts mehr übrig — file_get_contents('php://input') liefert einen leeren String, obwohl CONTENT_LENGTH einen echten Body ankündigt.
Der Request schlägt dabei nicht sichtbar fehl: handleUpdateMedia() fällt in diesem Fall auf reine Metadaten zurück (Titel/Kategorie unverändert), rex_media_service::updateMedia() läuft trotzdem "erfolgreich" durch (bumpt nur updatedate), die Antwort ist ein normales 200 {"message":"Media updated",...}. Der Client bekommt also Erfolg gemeldet, die Datei wird aber nie ersetzt.
Reproduktion
enable_post_data_reading = On(Standard).- Multipart-Request mit
method: PATCH(oder PUT) und einemfile-Feld anmedia/{filename}/updatesenden (z.B. perfetch()mitFormData+method:'PATCH'). - Response ist 200 mit Erfolgsmeldung.
- Die Mediendatei auf dem Server ist unverändert (Dateigröße/Breite/Höhe/Inhalt identisch zu vorher), nur
updatedatehat sich geändert.
Direkt verifiziert per Debug-Logging in parseMultipartInput():
AT HANDLE() START rawlen=0 CONTENT_LENGTH=2723 method_raw=PATCH FILES=[] POST=[]
boundary='----WebKitFormBoundaryXXX' rawlen=0
CONTENT_LENGTH zeigt den echten Body an, php://input ist aber bereits leer, noch bevor RouteCollection::handle() überhaupt mit dem eigentlichen Routing beginnt.
Mögliche Fixes
- In
handleUpdateMedia()vor dem Aufruf vonparseMultipartInput()prüfen, ob der Request tatsächlich als POST hereinkam (z.B. über einenX-HTTP-Method-Override: PATCH-Header geroutet) und in dem Fall$_FILES/$_POSTbevorzugen, die PHP dann bereits korrekt nativ befüllt hat. - Und/oder: In der Doku/im Code-Kommentar explizit darauf hinweisen, dass ein Client die Datei nur zuverlässig per echtem PUT/PATCH übertragen kann, wenn
enable_post_data_reading = Offgesetzt ist — das ist aber eine globale, invasive Einstellung (macht$_POST/$_FILESfür die GESAMTE REDAXO-Installation leer, betrifft z.B. auch den Login), in der Praxis für die meisten Installationen keine Option. - Alternativ die Route zusätzlich für POST öffnen (mit einem separaten Unterscheidungsmerkmal, z.B. einem Query-Parameter oder eigenen Scope), damit Clients native POST-Uploads nutzen können, ohne den PUT/PATCH-Semantikbruch zu riskieren.
Umgebung
- PHP 8.4.24, Apache/mod_php, Debian-Docker-Image (
docker-library/php) enable_post_data_reading => On => On(php.ini-Default, nicht projektspezifisch verändert)
Ich habe das für ein abhängiges Addon (MediaPlace) vorerst über einen eigenen, addon-internen Endpunkt umgangen (echtes POST an eine eigene Route, ruft serverseitig direkt rex_media_service::updateMedia()), wollte den eigentlichen Bug hier aber melden, da er wahrscheinlich jede Installation mit PHP-Default-Einstellungen betrifft, die versucht, media/{filename}/update mit einer neuen Datei aufzurufen.
- 主要言語
- PHP
- スター
- 20
- フォーク
- 0
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
FriendsOfREDAXO/api のほかの issue
-
Medien löschen hinter Web Application Firewalls blockiert (Pfad enthält /delete)対応中かも @skerbis が 5 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
FriendsOfREDAXO/api#84 ·
-
難易度 3/5 1〜2日 初心者へのやさしさ 65/100
FriendsOfREDAXO/api#83 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 55/100
FriendsOfREDAXO/api#80 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 55/100
FriendsOfREDAXO/api#65 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
FriendsOfREDAXO/api#62 ·
FriendsOfREDAXO/api の issue をすべて見る
似ている issue
-
needs-triage Technical TODO
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
メンテナーはふだん 2 日以内に返信
-
question
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
PrivateBin/docker-nginx-fpm-alpine#264 · コメント 1 件 ·
-
Fix test suite isolation by cleaning up registered theme directories and cache in teardown対応中かも @CookieDarb が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
WordPress/create-block-theme#895 ·
メンテナーはふだん 2 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 64/100
Piwigo/piwigo-docker#19 · リアクション 1 件 ·
-
[Store][SurrealDb] add(), query() and remove() fail with 403 on a fresh store instance対応中かも @lazerg が今日担当しました。 オープンBug Status: Needs Review Store
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信