Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

media/{filename}/update (PUT/PATCH): Multipart-File-Upload schlägt bei aktivem enable_post_data_reading fehl

Đang mở
  • Có gì không ổn?
#81 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
45/100
Loại issue
Lỗi
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Sôi nổi
Công nghệ
php
Lĩnh vực
api, backend

Hướng nghiên cứu

Bắt đầu bằng cách lần theo handleUpdateMedia(), parseMultipartInput() và route media/{filename}/update khi PHP enable_post_data_reading=On, tái hiện php://input rỗng với một PATCH hoặc PUT multipart. So sánh cách xử lý POST native, hành vi override method và phương án thay thế bằng POST-route được đề xuất; được xem là hoàn tất khi một multipart update thay thế ổn định file media thay vì chỉ cập nhật metadata, và response phản ánh kết quả thực tế.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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

  1. enable_post_data_reading = On (Standard).
  2. Multipart-Request mit method: PATCH (oder PUT) und einem file-Feld an media/{filename}/update senden (z.B. per fetch() mit FormData+method:'PATCH').
  3. Response ist 200 mit Erfolgsmeldung.
  4. Die Mediendatei auf dem Server ist unverändert (Dateigröße/Breite/Höhe/Inhalt identisch zu vorher), nur updatedate hat 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 von parseMultipartInput() prüfen, ob der Request tatsächlich als POST hereinkam (z.B. über einen X-HTTP-Method-Override: PATCH-Header geroutet) und in dem Fall $_FILES/$_POST bevorzugen, 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 = Off gesetzt ist — das ist aber eine globale, invasive Einstellung (macht $_POST/$_FILES fü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.

Ngôn ngữ chính
PHP
Star
20
Fork
0
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của FriendsOfREDAXO/api

Tất cả issue của FriendsOfREDAXO/api

Issue tương tự

Thêm issue về PHP

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.